NeoVim seems to bring these qualities into Vim sphere, giving the users and extension developers (in Emacs many extensions are apps themselves) better primitives to develop tools and applications, and allow to abstract-away Unix userland which is way too low-level and as I said above, not that friendly and helpful environment to live in. It holds on to what makes Vim interesting (modal editing, the range-command-object-movement style editing commands, ex mode) while adding a better API (VimL is...).
Still having trouble with identation, though. vim is just smarter ...
While that is still generally true in my experience, it helps a lot to set c-style indentation to linux-style instead of gnu-style.
From the top of my .emacs:
(setq c-default-style "linux"
c-basic-offset)C-j runs the command electric-newline-and-maybe-indent (found in global-map), which is an interactive compiled Lisp function in ‘electric.el’.
It is bound to C-j.
(electric-newline-and-maybe-indent)
Insert a newline. If ‘electric-indent-mode’ is enabled, that’s that, but if it is disabled then additionally indent according to major mode. Indentation is done using the value of ‘indent-line-function’. In programming language modes, this is the same as TAB. In some text modes, where TAB inserts a tab, this command indents to the column specified by the function ‘current-left-margin’.
With this I wholeheartedly agree. Without NV async would likely still be on the Vim wishlist. And if neovim wants a small donation I will gladly do that to say thanks.
However, now Vim does have async support as well, this use case is gone. NV needs to find the next one (and next and next). If their code is cleaner and easier to work on they will permanently overtake vim in features sooner rather than later.
Also, saying that Vim wouldn't have gotten the async features without Neovim is wrong. It would have come in sooner or later, Neovim sure made it a priority.
So they decided to write their own text editor that supported async plugins. Bram got butthurt and didn't want to lose a large portion of his user base, so he added async support.
NeoVim's first public release (version 0.1) was released in December 2015. [0] And you can see that Vim development really picked up in early 2016. [1]
Coincidence?
Anyway, both text editors are awesome, and Vim is better off now that it has competition. The async features would never have come without the competition of a rival project.
[0] https://neovim.io/news/2015/december/ [1] https://github.com/vim/vim/graphs/contributors
That is an unfair description. When it was submitted to Bram it was incomplete and not completely functioning, and he did receive feedback on it.
This is not true. If the work was not complete and not as how the lead maintainer/developer wants it. It is highly unlikely that it would be merged. I suggest you actually go and read the mailing list when this happened. I have seen it.
I could be wrong though. Please can you link the mailing list. (I can't find it) I'll read it and take back what I said, if that is the case.
Edit: spelling
https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/rTnUuZTg...
https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/skO2ee5k...
Personally the last post is the most important. He's basically saying that he knows there's clearly problems with his patch, but that he doesn't want to work on it until Bram takes the time to look at it and tell them what's wrong. He wants to push it in even though it's not 100% functional, to the point that he suggests merging it and calling it "experimental-timers".
The above isn't 100% related to Neovim, but below is the thread where Thiago Arruda essentially decides to create Neovim, and the other thread is brought up in this one which is why it is relevant:
https://groups.google.com/forum/#!searchin/vim_dev/Tarruda%7...
https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/VBLymmdW...
I recommend looking at the dates, Thiago posted the concept patch 12/4/13, and Christian ZyX responded 5 days later, and then Thiago responds that he's done working on the patch because of a list of reasons: One being he has heard stories of long response times from the Vim developers, Two being that 5 days was too long of a response time and that Bram hasn't responded to his patch, Three being that it was too complicated and he wouldn't be able to make it work, and Four being that he didn't want to work on it if it wasn't guarantee to ever get into Vim.
Let me know if there's a problem with the links.
VIM has been a stellar project that is due a lot of respect. Even the funding for VIM is reflected back to giving to Uganda children charity.
> NeoVim exists at all is because Bram Moolenaar refused to accept any patches for async support. People already did the work for him and he didn't want it.
Untrue: "It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly?
Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users." Brian Moolenaar https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
NeoVIM kind of said that VIM was just a mess and it would be impossible to grown past where it is. To me this was worst then Ubuntu having it's own Unity and Mir. This was just drama and seemed over the top disrespectful to Brian.
Neovim is very much to vim what vim was to Vi.
And Vi is what should be credited for the more important concepts found in those editors and their reproduction in IDE like the various Vi like plugins.
Braam losing a spiritual monopoly on such a great editor concept like Vi can only be a good thing.
For something you call worse than unity, it works pretty nicely, stable, fast, with far more readable code and is already on its way to become a great embeddable editor so that we can use the real Vi in IDE instead of pale imitations.
VIM originally meant "Vi IMitation". It wasn't till 1993 that it became "Vi Improved."
Actually VIM is not a direct fork of VI. VIM comes from Stevie editor from Atari ST and Amiga days. (I actually started with Stevie).
Here is the tree from ed to VIM
ed > Bill Joy and company then made em > en > ex AKA vi
Joy left development of VI in June 1979 and joined corporate life working with BSD.
vi (Unix\BSD) > Stevie editor (Atari ST) > VIM (Amiga)
Then chaos hit. From 1981 onward clones and implementations were incompatible and progress kind of grind to a halt due to license. That is when Stevie editor hit and then when Bram Moolenaar made VIM. He reimplimented it for Amiga and added features one being plugins. Vi had no plugins and very little customization.
Here is why your analogy is wrong: LICENSING "While commercial vendors could work with Bill Joy's codebase (and continue to use it today), many people could not. Because Joy had begun with Ken Thompson's ed editor, ex and vi were derivative works and could not be distributed except to people who had an AT&T source license."
So it is not at all like this fork. I find that people have taken sides without even knowing the history of VIM and make assumptions.
Due to _________ we are making a clone of this other product, but one that fixes ________, and therefore we are also attempting to co-opt the name a cutesy way so that people understand this is supposed to be, while not exactly the same thing, an equivalent thing (but with __________ fixed).
LICENSING (owned by AT&T the Oracle/Apple Grand Daddy of lawsuits in the 80s and 90s) and it was a port on an unsupported operating system, Amiga OS.
Also it was a clone of Stevie more so then Vi.
> but one that fixes ________
Vi TO RUN ON AMIGA OS (ADDED PLUGINS and CUSTOMIZED SHORTCUTS plus many other features not found in VI.)
Nothing in Neovim especially looking at VIM 8.0 is added but it is a refactoring with compatibility of plug ins with a cleaner code base.
I feel like people on NeoVIM side never really read the primary fights about the patch or understood why BDLF took a stand for a code more to his liking.
This is anecdotal speculation, but I imagine that most Vim users are in a similar boat. I talk to so many lifelong Vim users who have never even heard of "pathogen" or other plugin management systems. I'm pretty sure that heavy plugin users are the minority.
Most people who seem excited about NeoVim (or even talk about it at all), fall into three categories:
1) Heavy plugin users, who want plugins with some feature not well-supported by Vim.
2) Developers who would like to embed Vim within their own applications, but find the classic Vim codebase or license unsuitable for this.
3) "Ideologues". People who don't like Bram Moolenaar. People who wish he would have accepted a pull request that he declined or ignored. People who wish he would release Vim more frequently, make it more trendy, or bloat it up with this or that new feature. People who just don't like the way that the Vim project is run, ideologically speaking. (EDIT: i.e. the brigade crowd who's downvoting every comment that isn't unqualified praise and support for NeoVim.)
So like I said, I'm pretty sure that the overwhelming majority of Vim users do not fall into category #1. And the other two categories are tiny subsets of that first one. So to turn the question around... why WOULD people go out of their way to abandon the default, and flock to something else which might drift away from compatibility over time?
Now since I can do most of my work locally, neovim's terminal support has, for me, completely replaced my use of tmux splits. Having moved all my split usage out of tmux into neovim has simplified my setup and keybindings. And I grok and am more comfortable now with vim/neovim splits.
I actually am fixing up the install documents even though I don't use Neovim
I don't know how much it is used, but what are you basing that claim on?
Mind sharing some docs on how to do that?
`vsplit` splits the window vertically. `lcd` sets the bufferlocal working directory which is a new feature in neovim. `term ranger` launches the terminal emulator. If you wanted to be fancy you could add a toggle that reuses the same ranger instance which'd add an additional ~10 loc.
The nesting really is tmux -> Shell -> Nvim -> Ranger.
I do use psql's `\e` command to open the previous query in your `$EDITOR`, but that only lets me get the single previous query, and throws out any comments.
tnoremap <C-h> <c-\><c-n><c-w>h
tnoremap <C-j> <C-\><C-n><C-w>j
tnoremap <C-k> <C-\><C-n><C-w>k
tnoremap <C-l> <C-\><C-n><C-w>l
nnoremap <C-h> <c-w>h
nnoremap <C-j> <c-w>j
nnoremap <C-k> <c-w>k
nnoremap <C-l> <c-w>lI'd happily have switched if only for the code quality reputation. But it needs to be easy - no, that's too weak a word, it needs to be trivial - to install in the usual way I install things.
I see developers of the editor happy, which is a good thing, but IMO to get more users NV must show why it is better from a user perspective -- have several demos on the powerful things easily achieved with NV that are painful with Vim (via plugins is OK).
If NV devs can do this, it will go far. If not, then the case for an upgrade hasn't been made yet for most users. My 2c.