I am convinced that Vim's greatest asset and risk is Bram Moolenar. Bram is a talented, experienced developer, and I commend him for creating Vim. But he is the only person with write access to Vim's codebase. The primary author of NeoVim is Thiago de Arruda. Thiago tried to work with Bram, but was rejected.[1] Patches similar to Thiago's have been proposed before, but were also rejected.[2] It is for this reason that Thiago has forked Vim, and I wish him luck.
It's important to remember that everyone involved is trying to improve Vim as they see it. I think this is a prime example of how the benevolent dictatorship model can fail.
Do users mind that in your words Moolenar is a risk to vim, though? Are people specifically interested in the advancement of vim or just more generally in the progress of vim-like text editors, in which case they can happily switch to neovim if it becomes better than vim?
That is not the results of his labor. That is the means by which he achieves those results. There is an enormous difference. You're assessing the technical state of his project, and confusing that with its actual impact on the world. They are two different things.
I call him a "talented developer" because he has successfully developed and maintained (for two decades) a stable piece of software that is the base infrastructure on millions (billions?) of computer systems around the world. Millions of other developers rely on his work for their own work. I'll grant that maybe he has done this despite his engineering skills. But his software is a success by any reasonable measure, and I think it takes talent to achieve that.
I love code. I get an enormous pleasure of well engineered code. I appreciate code for its own sake. But code also serves a purpose, and I refuse to believe that someone whose code is so enormously successful somehow did so by accident, without talent.
I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin.
Although to be honest, making it part of core is vastly preferable, since it is a hard feature to get right (e.g., how do you deal with copy-pasting into multiple-cursors)?
Macros and global replace are substitutes, sure, but they're not at all the same thing. And while I'm no vim wizard, I have used it as my main editor for 4+ years, and have a 1500 line vimrc and plenty of plugins (including my own), so you don't get to assume I don't grok the vim way of thinking :)
I've heard the "macros is the same" sentiment many times, and usually it's from people who have never had much experience with multiple cursors, at least not in the situations where it's useful, and therefore don't realize how much more convenient they are in many every-day situations.
In fact, many of the people arguing against multi-cursors have been convinced after trying them that they are better.
Please, read my linked comment for an all-too-common situation.
The basic problem with macros and global replace is that they don't happen immediately and don't give you feedback. I don't know any vim user who hasn't had the distinct pleasure of needing 3 tries to record a macro before they got it right.
What's more, if I record a macro and run it, then realize after it that I want to do a small addition, I have to go through all the "setup" steps again - go back to the start, re-record, add the logical of finding the next block, and so on. I can't just visually see the situation and say "oh yeah, why don't I add this little tweak".
Seriously, take a very common example: having 3 if's one after the other, where you want to add a line at the start of each if block. Doing this with multiple cursors is a breeze - 3 buttons and you get 3 cursors, then write your code. And if, after writing it, you realize you actually want to add another line, you just keep typing. It's literally the same as typing.
Anyway, I've rambled enough on this topic many times. Please, just give them a try - I care a lot about text editors, I love this field, and I honestly think multiple cursors is the best innovation to happen in text editing in many years. And yet it's so often overlooked.
>In fact, many of the people arguing against multi-cursors have been convinced after trying them that they are better.
Fact by who?
>The basic problem with macros and global replace is that they don't happen immediately and don't give you feedback. I don't know any vim user who hasn't had the distinct pleasure of needing 3 tries to record a macro before they got it right.
True about macros, which are a very powerful tool that's way more than just multiple cursors. For global replace, however, this is false. Vim has an option to enable visual feedback for select/replace commands. I use it every day and it's awesome.
>What's more, if I record a macro and run it, then realize after it that I want to do a small addition, I have to go through all the "setup" steps again - go back to the start, re-record, add the logical of finding the next block, and so on. I can't just visually see the situation and say "oh yeah, why don't I add this little tweak".
What about recording the rest of the macro and running both of them one after the other?
>Seriously, take a very common example: having 3 if's one after the other, where you want to add a line at the start of each if block. Doing this with multiple cursors is a breeze - 3 buttons and you get 3 cursors, then write your code. And if, after writing it, you realize you actually want to add another line, you just keep typing. It's literally the same as typing.
v<linenum>j:s/if/<whatever>if/g
oh wait, I wanted to add another line?
uv<linenum>j:<up><change regex>
Also as somebody already pointed out, vim already has plugin(s) for multiple cursor support and they work exactly as they should.
I'm not arguing against multiple cursors, I'm just saying that they don't really bring anything new.
By me. I've talked to people and they've changed their minds. Sorry, should've made that explicit.
>What about recording the rest of the macro and running both of them one after the other?
Because sometimes you only think of it later.
>Also as somebody already pointed out, vim already has plugin(s) for multiple cursor support and they work exactly as they should. I'm not arguing against multiple cursors, I'm just saying that they don't really bring anything new.
As I mentioned to them, I used that plugin, and while it's awesome and I totally love the author for making it, it just isn't as good. See my other comment for details.
And again, I really disagree that they don't bring anything new. That's like saying that WYSIWYG text editors don't bring everything new over systems like Latex. Can you do everything in both systems? Yes. Is it sometimes easier to just select text and hit "ctrl+b"? Yes. Is it always better? No. But it's good to have both options, as sometimes one crushes the other.
Again, I love vim, and I definitely use some of the very methods you've mentioned. But I'm not here to sell you anything, I don't earn anything by convincing you to at least give multiple cursors a shot, except knowing that if you're dismissing them without having tried them then you're missing out and that makes me sad.
Just to add to that, you can also use visual block mode to change text on multiple lines. You get a lot of the benefits of multiple cursors that way while still doing things in a more traditional "vim-like" way.
No reason not to do things in a vim-like way with multiple cursors. In fact, they're literally just an extension of the block-mode concept, except that it's just better because it allows you to do a superset of things.
> [I] have a 1500 line vimrc and plenty of plugins (including my own), so you don't get to assume I don't grok the vim way of thinking :)
This may only show that you grok VimScript way of thinking, not Vim way of thinking.
You need not re-record a macro, a macro is stored in a register. Just edit the register, and you're good to go with you new, (supposedly) improved macro.
In Vim, you edit in Normal mode, and insert in insert mode. Multiple cursors is a means of moving editing into insert mode, and thus in spite of the Vim way. I am an Emacs user * and there is a multiple-cursors mode for Emacs, which quite useful as Emacs is modeless.
* If we're doing SLOC porn here, I've a ~400 SLOC vimrc with nice gems in it, and is nicely and extensively commented. I've switched to Emacs for my love of Lisp and newfangled dislike of some parts of Unix.
"This may only show that you grok VimScript way of thinking, not Vim way of thinking."
True enough that it doesn't prove anything.
"You need not re-record a macro, a macro is stored in a register. Just edit the register, and you're good to go with you new, (supposedly) improved macro."
I know. And if you think this process is easier, faster, or saves keystrokes over using multiple cursors, then I think you're wrong.
"In Vim, you edit in Normal mode, and insert in insert mode. Multiple cursors is a means of moving editing into insert mode, and thus in spite of the Vim way."
No no no! That's the beauty of using multiple cursors in vim. You can have (potentially) multiple cursors in Normal Mode, and use all the normal vim commands. That's what makes it so sad that it doesn't have multiple cursors, because if you can merge the power of multiple cursors with the power of vim, you get something amazing.
Imagine having the following:
<pre>
<div>some text</div>
<div>Some other text</div>
<div>Third</div>
</pre>
Then imagine you want to, for some reason, copy-paste the contents of the different divs into (say) another buffer.
With multiple cursors, you can select the three lines, use the vim commands to yank the text object that's in between the divs (yit), and then paste it elsewhere. This is not possible in Sublime Text, since it has no way of saying "select text between divs". Or even, doesn't have vim's "f" command so one could jump to the "<" character opening the second div.
Well, I can copy the divs over, then run ":'<'>s/<\/\?div>//g". Or, if the divs were aligned nicely, I'd copy the divs except for the opening tags via block selection, then on the result of pasting, I'd run ":'<'>s/.\{6\}$//". The difference with the multiple-cursors way and the Vim way is that, the above regexps can be used, without modification, on ranges of variable amounts of lines, whereas, the multiple-cursor way is not as flexible to get adapted to handle variable amount of lines as far as I can imagine.
Vim poses a way to edit text; Sublime, Emacs and other modeless editors pose another. One enables neat tricks via a very nuanced and powerful editing language, that is Vim verbs, text objects et cetera, and the rest do not provide such mechanism, in favour of simplicity and ease of use (it is easier to start typing in Emacs than Vim, whereas it is easier to do editing in Vim than Emacs, but only for the knowledgeable user).
Do not get me wrong, I am not thinking multiple-cursor-editing is useless; in fact, I use it quite a lot in Emacs[1], and I like how it indeed helps me do my multi-line editing with instant feedback. My argument is that such editing has little to offer to a user that has spent a month-or-so to master Vim.
My .vimrc used to be large, but now has dwindled down to a handful of simple commands. I've simply adapted to be maximally productive in a nearly pure vim environment. Does this make me less of a vim user?
> What's more, if I record a macro and run it, then realize after it that I want to do a small addition, I have to go through all the "setup" steps again - go back to the start, re-record, add the logical of finding the next block, and so on. I can't just visually see the situation and say "oh yeah, why don't I add this little tweak".
this is very doable, lets say you record a macro to 'a'
1. q:
2. let @a='
3. ^r^ra to put in the current contents of the macro
4. edit as you see fit
--- you should now have something like ---
let @a='contents of macro'
5. ???
6. profit
Say I want to edit those two numbers. With multi-cursors, it's as simple as select one number, hitting a button that causes the other number to be selected, then writing the new value.
Now, after I wrote it, I realize I forgot to put a space after the colon, and want to change the formatting. No problem - I just make the change to the first line, and the next line follows.
Same as macros? Kind of. But let's say I make a mistake in the macro, e.g., I move the cursor left to the beggining of the line letter-by-letter instead of hitting "home", which is a killer for a macro since each line is a different length. (this is a contrived example a real vim'er will never do, but there are plenty of real examples of 'oops forgot about that' things when recording macros).
Anyway, when I run my macro, suddenly things won't work, and then undoing and starting the re-record process takes time. But if I'm doing this with mulitple-cursors, I see right away, visually that something's wrong, and it's easy to fix - I just hit "home" after moving the cursor left.
And note - this is a drop-dead-simple use case that happens 10's of times a day for any css programmer. Similarly, most programmers will run into cases where they have two similar if blocks one after another, or two similar "except" blocks, and so on.
And that's not even going into lots of other, very powerful cases, like taking a function that gets a list of paramaters, and being able to easily manipulate these paramaters, e.g. given "foo(a, b, c, d, e)", I can easily multi-cursor all the commas, then copy all the params, then paste them after the func definition, hit enter, and I've got a list of all the params after the function definition. And this isn't hard, at all! I visually see everything I'm doing as I do it, and if something goes wrong, I fix it on the spot.
I could ramble more about this, but I think I've either convinced you I'm crazy, or at least to try multi-cursors out :)
If you do this kind of editing daily, then executing the following commands would become second nature
:s/50/60/g
:s/:/: /g
No need to touch the mouse or use macros. Many use-cases for multiple cursors are satisfied by the core functionality of vim, however they may not be immediately obvious.
Alright, but in more complicated cases you have to bust out macros, and they're just plain harder since they don't give visual feedback.
Take an example like the following:
def foo():
// do stuff
def bar():
// do stuff
Now I want to change my comment to say:
// The function foo does stuff
With multiple cursors, I select both def's, copy the following word, then go down and change the comment.
Again, I'm not saying this can't be done in vim. But it's just plain easier to do with multiple cursors. And if you don't believe me, well, that's your right of course. But having used both, extensively, I'm telling you - please, at least give it a try. For many daily use cases, it's just so much easier. And I don't get anything out of selling you on multiple cursors except for the warm fuzzy feeling of maybe helping a fellow developer learn something that will help them.
More serious response: I think after many years of training ones brain to use the features available to it some of those features become second nature and subconscious. This is great for editing and it's the reason I immediately saw that you left me a really easy way to do it, but it can make seeing the value of new features more difficult.
I run into examples like this a lot and have yet to find an elegant way to deal with it. Honestly, I'd like to see if there's a simple solution.
I find that I spend a lot of time in my editor crafting regular expressions to do clever replacements and I've yet to get so good at it that it doesn't distract me from my editing.
I see the point, but when you have to duplicate the code like here for the `50px`, you should use something like SASS/LESS to put the value in one place and then use a variable everywhere.
I don't particularly need or use the feature over block selection or find and replace but it's similar to an interactive find and replace where you don't need to edit every instance of the found term. Some people love it.
It works, and definitely better than other tries, but it's not even close to Sublime Text's caliber. Through no fault of the author, I assure you, as someone who's tried his hand at creating a similar plugin for vim and found many limitations of vim.
One easy limitation comes to mind - you can't copy-paste different cursors, then paste them as unique items. E.g., given a list "a, b, c", I want to be able to multi-cursor the letters, copy them, then paste them into 3 multi-cursors somewhere else. Hard, very hard to implement.
Do you have any links to a description of how they should work or should I just use Sublime Text to see a canonical example?
That doesn't sound hard to implement iff you plan for those features from the beginning. I have my own editor hobby project and during my reading I got convinced multiple cursors are great for the reasons you described in your other comment.
I hadn't thought about multi cursor copy/paste so I'm wondering what else I've missed.
Someone posted a demo video of a modal text editor with multiple cursors to HN a year or so ago and I've been trying to track it down. Any idea what that might have been?
Maybe I'm not understanding the example, but is what you're suggesting (copy/paste) even possible in sublime? The github plugin above is the closest I've seen to sublime's version. It's not perfect, but works for most of the basic use cases.
Yep, possible in Sublime Text. It's one of the harder things to get right, and Sublime also has (or had) weird behavior, but most of the time copying 20 items with 20 cursors and pasting them to 20 cursors works great.
I feel like one of the main goals of neovim is to make it more like emacs. Or guile emacs.
Instead of a shitty language for plugins and configuration: vimL (with some support for plugins in alternative languages but not well integrated and not present in all vim installations) and replace it with a good interface to a single language. Like emacs. Much of emacs is written in elisp instead of c, I wonder if this will enable quicker/higher level development with lua for parts of neovim.
The plans for a compatibility interpreter for vimL on top lua sound a lot like the elisp on top of guile plan for guile emacs, and isn't one of guile emacs goals to add support for concurrency?
Both vim and emacs have had problems recently in balancing refactoring needs and their traditional architecture and project layout.
People are more and more used to contributing to projects with an occasional pull request. However to benefit from this, the projects have to become more accessible to these people. This makes all those changes that are introduced to neovim necessary. If tests are already beneficial for a developer who has written the codebase, the occassional contributor really depends on them.
Vim and emacs are projects that are of special strategical importance to the world. They must not vanish.
Thiago claims that one of Vim's biggest problems is its lack of testing infrastructure. It is difficult to refactor or make changes without the chance of introducing some possibly obscure regression. This is probably a big part of Bram's reluctance to merge large changesets from other developers.
I honestly thing if he can successfully pull off this "msgpack UI" and get a solid set of tests written (which the community seems eager to start work on) this project will be a huge success.
Here is his quote from the mailing list:
"This may not be so obvious, but vim's biggest problem has nothing to do with the lack of the above features. It's something much more basic: poor testing infrastructure.
While vim has some automated tests(about 200 counting with the ~100 tests embedded in test 49) those only catch the 'biggest' bugs, with many small ones being introduced by patches and only detected at a later time. It's a true maintenance hell, and here's a post on reddit that illustrates the problem(even though the author himself disagrees with neovim): http://www.reddit.com/r/programming/comments/1yjzez/neovim_a...
The problem is that in it's current state, vim cannot grow because there's no easy way to write automated tests for it. The current test suite is very hard to understand and those that submit patches probably won't write tests because it's too complicated. But patches need to be tested, especially bug fixes which must acompany a regression to ensure they won't be reintroduced. So it's easy to see why Bram is skeptical about merging patches, especially new features: He has no way of knowing if those patches will break existing code. In the example given by the reddit comment, Bram 'solved' the problem by simply picking the lesser of two evils.
This is one of the firsts issues neovim aims to fix: By writing a msgpack 'UI', we'll be able to write well-documented functional tests in a high-level language. Contributors reporting bugs will be able to reproduce them with a test cases and new features will be properly tested. As the test suite covers more code, neovim will be more 'protected' since there will be a bigger chance of catching bugs the minute a PR is sent(with travis). People need to understand that before posting issues regarding new features or new ideas, as neovim must be properly 'secured' against bugs first."
The whole approach makes a lot of sense. Successful refactoring goes hand in hand with setting up a test environment. Code that is not covered by unit tests is legacy code. Without tests, you have to fear breaking things and fear is a bad starting point for development.
I backed Neovim and I really hope that it succeeds. I think the Vim codebase is criticized a little too harshly in general. It is a child of its time.
Whether Lua is the optimal choice as an extension language remains to be seen, yet it is a very pragmatic choice and over time we will see that the C core of vim will shrink dramatically.
I seriously hope that Bram Molenaar is not offended by the fork (and I think he is not). For the vim community having neovim as an independent development line will have its merrits until it is clear whether the fork can replace the proven editor.
Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds?
The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell of a lot.
Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so.
As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals.
Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.
Vim is -- the default on many systems, shipped with fully working vi compatible mode, has literally millions and millions of users. It can not -- by its nature -- move fast and break shit. Vim has a much, older, slower development process -- from the days well before Github and friends... it might slowly open up -- but not much, because again, millions depend on it. This is also, awesome.
I hope the very best ideas, once they are tested, debugged, and tested again will make their way up from Neovim to Vim, but it will be a very slow process. Neovim gives no thought to Vim -- because it can't -- it has to be its own thing to move forward. Vim gives no thought to Neovim yet -- it is an established, dependable, amazing tool... and Neovim has not yet risen to the point to even be worthy of a response.
I don't want a product that moves fast and breaks things, but I also don't want to carry the baggage of legacy support for strict vi-mode and whatever else ungodly edge cases vim continues to support.
What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's needs better than saying "fuck it I just want Sublime with better vim bindings". An editor is not something where I want to chase the flavor of the month and deal with constant plugin breakages, but neither is it something where I want to be stuck in the 90s forever. There has to be a middle ground.
For the time being Bram's approach has earned my trust, and Neovim has to demonstrate many years of good project management and momentum before I will really be willing to trust it.
Those ungodly edge cases are what makes vim usable everywhere, and the default of the defaults on so many systems. That trusty vi command that works a certain way has been dependable since the late 1970s.
But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim.
The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.
I am moving over to VIM because I disagree with some of the design decisions - for instance, I don't believe in a single gatekeeper to a application that I depend upon.
> Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.
The first thing done to Neovim was to re-format all the code and then do some refactoring that breaks things. You can't make an omelette without breaking eggs but this practically burned the bridges behind and any hope of merging stuff upstream/downstream from neovim to vim or vice versa is gone. At least without significant manual labor.
If you ask me, this was a premature move and the neovim guys should have tried to make non-breaking changes first with an opportunity for upstream-downstream merges.
The Neovim development path -- by design -- had no chance of upstream-downstream merges. It is a departure, not a premature mistake, but a decision.
The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.
I do not know how much manual labor it is, but there are some pull request with merge of vim patches, so it definitely is possible (or at least someone thinks it is worth their time).
Quoting his answer [1] in the vim_dev mailing list:
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.
I've only seen his original post on it [0] - not sure if anything had changed since then.
For selfish reasons I'm behind neovim but I can see that it puts Bram in a bad position, which is unfortunate. He's done so much work for all of us (vim users), and ultimately this project just adds to the work he has to do (and makes it even more thankless). He'll be dealing with incompatibility issues between plugins trying to support both systems.
Ultimately, I guess he'll have to make a choice as to which codebase to support, by choosing neovim he's deserting everyone on esoteric systems. I think that may be the best outcome; Neovim becomes the new standard, Bram switches over and leaves vim to die. But then what control does he have?
It's one of those situations, it seems like a good idea, and could be a massive net win. Then again, it could also really destroy the project.
Thanks for the feedback. I created the poll so I'll be sure that when we create the Bounty we are clear in that the underlying API is what we are looking to improve.
Others have probably already said this elsewhere, but I think high quality error messages for vimscript (or the lua api) are one of the most important things. The project already cares about the developer experience for people writing plugins. Error messages are a difficult but important part of that.
I've always wanted to write Vim plugins, but Vimscript and the RPC contortions always looked too hairy for me to get involved -- I'm excited for the new vim-embedding interface so I can get real VIM compatibility with my IDEs.
I tried it. For now it just behaves the same as normal Vim. Most of the work done is indeed under the hood. They are refactoring the codebase so that it will be easier to create plugins, extentions and to use Neovim inside other apps.
It works like the javascript event loop, so even though Neovim is still single-threaded, you can dispatch to external processes and handle the results in a callback(s).
The code base is now about half of the original size (removed support for legacy OSes, swap all native IO abstractions for libuv, removed dead code, etc). They also split the 25Kloc files called things like misc2.c into multiple files and neovim uses cmake instead of a slew of hand written make files with two decades of commented out hacks. Work on a vimscript -> lua compiler (https://github.com/neovim/neovim/pull/243) is underway as well as the new RPC plugin stuff (https://github.com/neovim/neovim/pull/582).
I've been skimming the newsgroup(s) and browsing the commit logs for the past few weeks. It is definitely progressing.
I think they didn't quite realise how many people were going to want to be part of it, during the fund raising, and so a lot of effort has gone into coping with the large amount of work from multiple people, merging in patches from the 'main' VIM trunk, etc.
There's been a huge amount of pruning - which is still on-going - of old deprecated stuff. For instance, the X11 interface stuff is being simplified (for now) into just the GTK interface.
The original author of the neovim concept (Thiago) just posted: https://groups.google.com/forum/#!topic/neovim/R_jXItMXN4E saying that now he actually has someone to take over a lot of the community stuff, which should free him up to work hard on some of the original actual coding fundraising goals - which is excellent.
In some ways, thinking about it, it's probably good that he delayed it, as it means that there's been a lot of extra eyes going over the code of the whole project cleaning things up so that the new features aren't going to conflict too much with other bits being removed.
There's one of the guys who's a vimscript genius working on the lua/vimscript side of things, which will get merged in at some point once it's ready. It's essentially a completely separate project until it's ready though.
I suspect the first of the big project 'features' to be done will be the libuv stuff - which again, will have little to actually see as a user. Once that's done, and then the lua scripting stuff is done, after that then new features are possible.
Even now, though, the difference in the code is dramatic, and it's constantly getting minor cleanups and improvements along the way.
I wonder where that rumor started, but I responded to a similar assertion on reddit[1].
To summarize:
* Uncrustify was literally one of the first things that was done before Neovim was even announced. It's only listed in the "progress" page for completeness and reference.
* The refactoring is ongoing and is moving along smoothly.
* Job control ("async") is committed, and it works. You can use it today.
The goal (as I understood it) is to separate back-end and front-end. That is, you could have a CLI front-end with just text interface, or a GUI front-end with all the fancy features.
Maybe I didn't get the point of neovim but I don't really see how a GUI could be a useful addition for vim.
I only use gvim because colorschemes have nicer colors.
They are willing to make it more like gvim, running in a separate window, and one of targets of neovim is to use a modern graphics backend to achieve that.
neovim is sticking with the standard fixed terminal as the 'main interface', but is building a better/easier way to communicate with external processes. That way a non-terminal Vim plugin can open up extra windows for minimaps, etc.
Ideally, this would mean you could have a vim "server" (for lack of a better term) on your dev VM, or where-ever, and local "client" windows on your actual workstation which displays beautiful helptexts, minimaps, code trees, etc.
If that's not a command line application anymore. What's the point of keeping the "vim" name apart from teasing users?
Call it neogvim or neogvimlikenotepadforjsfullstackdevelopper
You're free to continue using Vim, no one is taking that away from you. And if you would bother to read up on the project, you'd see that one of its primary goals is to separate the actual editor from the visual interface. That way, everything that is GUI related is separate.
It's important to remember that everyone involved is trying to improve Vim as they see it. I think this is a prime example of how the benevolent dictatorship model can fail.
1. https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ
2. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...