Neovim's Next Feature Poll

http://neovim.org/development-wiki/polls/

by tambourine_man • 12 years ago

118 96 12 years ago

seren• 12 years ago

Has anyone used neovim yet ? Is it usable ? Is there any new features or are they only refactoring under the hood ?

gitaarik• 12 years ago

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.

metrix• 12 years ago

It seems to be in a working state, and loads VERY fast. But I haven't tried modifying the nvimrc or use plugins.

justinmk2• 12 years ago

For now it just behaves the same as normal Vim

Not quite. Neovim has working job control ("async"):

http://pastebin.com/hpiCP9Ae

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).

joelthelion• 12 years ago

I think they should focus on refactoring the core and letting people add features through plugins.

gaving• 12 years ago

Loving the progress of Neovim so far, even better that notable plugin authors (https://github.com/neovim/neovim/issues/622#issuecomment-415...) are getting involved.

jitl2• 12 years ago

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.

pekk2• 12 years ago

Except it has been possible for a long time to write scripts in other languages so what are you talking about?

pekk2• 12 years ago

What do people have against Bram Moolenaar? Vim is good already without a coup.

hedwall• 12 years ago

Neovim has not been started to spite Bram, why would you think that?

SeoxyS• 12 years ago

How could they make a sublime-style code minimap in a CLI app?

martius2• 12 years ago

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.

deckiedan2• 12 years ago

Nonsense, mate.

https://groups.google.com/forum/#!topic/neovim/hTPKGGzwWKA

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.

kachnuv_ocasek• 12 years ago

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.

kleim• 12 years ago

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.

threatofrain• 12 years ago

I've heard from a HN commentator that Neovim has given up on its principle goal of refactoring, and that progress has largely been due to uncrustify.

Can anyone else speak to the health of the project?

deckiedan2• 12 years ago

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.

kansface• 12 years ago

Have a look for yourself: https://github.com/neovim/neovim/commits/master.

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).

justinmk2• 12 years ago

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.

[1] http://www.reddit.com/r/vim/comments/23xgxv/tim_pope_is_flir...

mikaelj4• 12 years ago

"Sublime minimap" and "better autocomplete" are features that use an underlying API.

I'd prefer if they could be renamed to "Fetaure X which enables e.g. sublime minimap" and dito for autocomplete.

davis2• 12 years ago

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.

mikaelj4• 12 years ago

I don't follow - it is /not/ clear to me which underlying API it is that will get implemented by voting for "sublime-style mini-map".

hk__23• 12 years ago

There’s a typo in the news title: it’s “poll”, not “pool”.

joshgel• 12 years ago

I thought we were going swimming!

dang• 12 years ago

Thanks. We finally changed it.

Galanwe• 12 years ago

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

adamors• 12 years ago

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.

dasil0032• 12 years ago

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.

bpierre• 12 years ago

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.

[1] https://groups.google.com/d/msg/vim_dev/x0BF9Y0Uby8/94tmiaBv...

mikaelj4• 12 years ago

The refactorings thus far have been specifically aimed at making Neovim work better for /developers/. Which in turn will make it better for the users.

A very good way of thinking.

CyberMuz• 12 years ago

He is not very enthusiastic about it. Here is his comment about Neovim from two months ago. I don't know if he changed his mind in the meantime. https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

aidos• 12 years ago

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.

[0] https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

MetaCosm3• 12 years ago

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.

exDM69• 12 years ago

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.

dasil0032• 12 years ago

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.

chroma• 12 years ago

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.

1. https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ

2. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

omaranto• 12 years ago

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?

edanm12• 12 years ago

Please, please implement multi-cursor support. For anyone that doesn't agree, please read my previous post on HN on the topic: https://news.ycombinator.com/item?id=1625382

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)?

hk__23• 12 years ago

What problems can you solve with multi-cursors that you can’t with actual features like block selection?

weaksauce2• 12 years ago

Editing the same thing in different places at the same time.

edanm12• 12 years ago

Simple (very common example):

<pre> .some-css-rule { padding-left:50px; padding-right:50px; } </pre>

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 :)

Morgawr2• 12 years ago

But vim already has multiple cursor support, and arguably even better tools that do the same job.

edanm12• 12 years ago

Please see my answer to another commenter. I really disagree with this, and urge you to at least try it out.

(and vim doesn't have multiple cursor support in the sense that I mean it).

Afal• 12 years ago

you can get multiple cursors with this plugin (works better than I expected) https://github.com/terryma/vim-multiple-cursors

edanm12• 12 years ago

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.

beaumartinez• 12 years ago

Vim doesn't need multiple cursor support. Train yourself to think in Vim—you're editing text and words, not moving a cursor.

Macros and global replace already do what you want.

edanm12• 12 years ago

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.

indralukmana2• 12 years ago

So anyway, where is NeoEmacs?

*i am going to run now.

cube_yellow• 12 years ago

"NeoEmacs" is guilemacs, putting emacs ontop of the guile vm. look at the GSoC project.

indralukmana2• 12 years ago

Oh, i just learn about this.

But when i search google for this guilemacs there are no definitive information for this project (as in where i download the program?).

So based on my little browsing, vim and emacs have some kind of different problems? (or are they even problems?)

Vim has the benevolent dictator who prefer supporting backwards compatibility to developing features. And Neovim try to address that.

Emacs is using a "hacky emacs lisp" and "guile emacs" tries to incorporate a scheme based improvement on the backend.

gcao• 12 years ago

Has anyone created mapping to jump AFTER a character? I did it and think it is great.

manolus• 12 years ago

The greatest thing implemented in neovim, IMHO, is this feature: https://github.com/neovim/neovim/pull/475

afarrell• 12 years ago

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.

rat87• 12 years ago

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?

wirrbel2• 12 years ago

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.

js2• 12 years ago

"pool" vs "poll" - can the submission title be corrected?

rektide• 12 years ago

Terrified that multi-cursor would be for the case of "one user/keyboard/mouse." I'd love to see a Vim that actually does multi-seat.

Simucal• 12 years ago

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."

wirrbel2• 12 years ago

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.

Neovim's Next Feature Poll

Related Stories