
Neovim's Next Feature Poll - tambourine_man
http://neovim.org/development-wiki/polls/
======
chroma
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](https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ)

2\.
[https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...](https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%5B1-25-false%5D)

~~~
omaranto
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?

------
edanm
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](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__2
What problems can you solve with multi-cursors that you can’t with actual
features like block selection?

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

~~~
chunkstuntman
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.

~~~
astine
Trivial counter-example:

    
    
      .some-css-rule { padding-left:50px; padding-right:50px; margin:50px; } 
    

Pretend you want to avoid changing the margin.

~~~
chunkstuntman
:s/50/60/g<CR> @:

or even just /50<CR>r6n.

if there's any new feature I'd like to see in neovim it would be one key that
will repeat an ex command like period does for normal/visual mode

~~~
astine
You're first example wont work. What you want is

    
    
        :s/50/60/<CR> @:
    

And that still won't handle

    
    
        .some-css-rule { margin:50px;  padding-left:50px; padding-right:50px; }
    

The second example will work, for this, but not for the situation where you
change your mind halfway through and decide you want 70px instead.

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

~~~
wirrbel
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.

------
Simucal
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...](http://www.reddit.com/r/programming/comments/1yjzez/neovim_a_project_to_refactor_and_modernize_the/cfla7j5)

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

~~~
wirrbel
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.

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

~~~
MetaCosm
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
> 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.

~~~
MetaCosm
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.

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

~~~
davis
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.

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

~~~
davis
Possibly this will answer your question?
[http://www.reddit.com/r/vim/comments/1yqqhl/bram_responds_to...](http://www.reddit.com/r/vim/comments/1yqqhl/bram_responds_to_neovim/cfmxjb9)

~~~
mikaelj
I did not ask a question - I wanted the _poll_ to clarify what architectural
changes were to be made in order for the minimap feature to exist. :-)

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

~~~
joshgel
I thought we were going swimming!

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

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

~~~
jitl
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.

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

~~~
jitl
I guess I should've been clearer: I want to embed Vim in other applications
and environments without having to write three crazy bridges between them

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

~~~
gitaarik
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.

~~~
justinmk
> For now it just behaves the same as normal Vim

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

[http://pastebin.com/hpiCP9Ae](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).

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

~~~
kansface
Have a look for yourself:
[https://github.com/neovim/neovim/commits/master](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](https://github.com/neovim/neovim/pull/243))
is underway as well as the new RPC plugin stuff
([https://github.com/neovim/neovim/pull/582](https://github.com/neovim/neovim/pull/582)).

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

------
manolus
The greatest thing implemented in neovim, IMHO, is this feature:
[https://github.com/neovim/neovim/pull/475](https://github.com/neovim/neovim/pull/475)

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

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

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

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

~~~
kachnuv_ocasek
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
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.

~~~
mseidl
You can use CSExact to get GUI color schemes to work.

[https://github.com/KevinGoodsell/vim-
csexact](https://github.com/KevinGoodsell/vim-csexact)

There is also csapprox.

------
indralukmana
So anyway, where is NeoEmacs?

*i am going to run now.

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

~~~
indralukmana
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.

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

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

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

