Neovim

10,586 views
Skip to first unread message

Diego Viola

unread,
Feb 23, 2014, 4:29:16 AM2/23/14
to vim...@googlegroups.com
Hi Bram,

I would like to start by saying that I admire your work on Vim, I've been using it for quite some time now and I really enjoy using Vim every day.

There's a new project that is called Neovim that seeks to refactor and modernize the codebase, I was interested in knowing what your opinion is on this project? I think many are curious about what you think too.

Please let us know. Thanks for Vim. :)

http://neovim.org/
https://github.com/neovim/neovim

Regards,

Diego

Bram Moolenaar

unread,
Feb 23, 2014, 2:44:42 PM2/23/14
to Diego Viola, vim...@googlegroups.com
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.

--
WOMAN: Well, 'ow did you become king then?
ARTHUR: The Lady of the Lake, [angels sing] her arm clad in the purest
shimmering samite, held aloft Excalibur from the bosom of the water
signifying by Divine Providence that I, Arthur, was to carry
Excalibur. [singing stops] That is why I am your king!
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Marc Weber

unread,
Feb 23, 2014, 5:51:48 PM2/23/14
to vim_dev
Excerpts from Diego Viola's message of Sun Feb 23 09:29:16 +0000 2014:
> I would like to start by saying that I admire your work on Vim, I've
> been using it for quite some time now and I really enjoy using Vim
> every day.
For a long time quite some things did bother me. They don't affect
regular users only editing texts. But they do affect programmers who
want to write fancy extensions. There are "workarounds", such as
vimproc, vim-addon-async (eg for async communications), but at least the
-async workaround is a ugly hack. sample features it provides:
- ruby debugging
- php debugging
- ruby/scala/python repl with completion
I'm not going into details. the wiki link below lists more (please add
or edit if you think I'm wrong - you can do so)

I personally get annoyed always when not having touched ~/.vimrc and get
vi instead of vim (without file name completion - I really think such
things should be fixed - who is using vi behaviour for what reasons?

If you want some vi behaviour it is the time to tell tarruda about what
you care.

Another simple use case is: :ruby and :py commands cannot be interrupted
by ctrl-c like (viml) - and the viml implementation is based on gtk
event loops (gui) which also runs resize viml autocommands arbitrarely.

Of course you can workaround it - but being ablte to abort an infinite
loop you wrote by accident is helpful - or if a script takes too long
for whatever reasons.

tarruda will put if_* into separate threads (I hope he'll succeed) -
and that might fix such small things.

So there are quite a lot of "weak" reasons summing up IMHO.

I've posted about this list earlier:
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html

Bram is right: In current state Vim does get most use cases done
"reasonably well". In fact it would have been me starting such a
crowd funding project if I would have been satisfied with C/C++ (But I'm
not).

There are alternatives, eg rust: rust-lang.org - but I'm unsure how
stable it is at the moment (eg the release doesn't compile the
rust-csv library at http://www.rust-ci.org/projects/). That's why I
personally limited myself to writing down what I'd like to change.

For a lot of users neovim might not change too much - but for those who
want fancy features it could make a big difference - if tarruda gets
things done the way he described.

Some of you may remember my thread and my page: http://mawercer.de/vim.php
I forwarded all people to tarruda who either filled in this form or told
me that they'd assist. So those about 5-7 people will get contacted by
him hopefully.

Despite all flaws Vim is still the editor of my choice.
Patching is a lot of work, rewriting would be a lot of work,
alternatives exist (eg Yi, written in Haskell) - so finding "one true
upstream" without splitting the community is not simple.

Is it worth the effort? Depends on your use cases - It might be that Vim
lives as long as the linux kernel - so the future might be even longer
than its past - who knows? Then it will pay off for sure (IMHO).

Was it the first fork? No, See YZis short description here:
http://www.freehackers.org/VimIntegration
(YZis dropped VimL only supporting lua - and most Vimmers depend on a
lot of viml plugins ..)

I hope that NeoVim will succeed - and that we don't split community too
much.

Marc Weber

Michel Albert

unread,
Feb 24, 2014, 3:29:47 AM2/24/14
to vim...@googlegroups.com

While I agree that there are a couple of things in vim which are annoying, I /think/ (correct me if I'm wrong) Bram was primarily addressing another issue: Total vs Partial refactoring.

In my opinion total refactoring is rarely a good idea. The more time and effort went into a project, the riskier it gets. So many years of usage experience went into vim. This means the existing code addresses a vast number of corner cases which crept up during the years. Total refactoring risks an insane amount of regressions.

Partial refactoring is harder (depending on the case, a *lot* harder) and will take longer but is not risking as much. And not to forget, has a chance to get merged into the mainline code.

The "total refactoring path" is something that pains a lot of the open-source world. It happens so often that an existing project is forked by people who intend to re-write it in a better way. Their intentions are noble. But only few of them succeed.

Matteo Cavalleri

unread,
Feb 24, 2014, 3:40:04 AM2/24/14
to vim...@googlegroups.com
> So many years of usage experience went into vim. This means the existing code addresses a vast number of corner cases which crept up during the years.

that's why Bram wants a test for every patch ;)

I don't have the expertise to say which path would be the best for neovim, but at least tests should make refactoring a lot easier. I'm more worried about refactoring the code and, at the same time, change / add stuff (like the new plugin system)

Jan Larres

unread,
Feb 24, 2014, 4:29:38 AM2/24/14
to vim...@googlegroups.com
Michel Albert <exh...@gmail.com>:
> Partial refactoring is harder (depending on the case, a *lot* harder)
> and will take longer but is not risking as much. And not to forget,
> has a chance to get merged into the mainline code.

The problem with this approach is that everything would still have to go
through Bram, which is one of the major hold-ups for many patches that
already exist and that arguably improve things. Bram is certainly doing
a great job with the time he has available, but he's still a bottleneck
as he is only one person. That has led to the todo list getting longer
instead of shorter and many patches, including three different
approaches for asynchronous processes, just languishing there. So in
addition to the refactoring I think that a more flexible development
model that is not dependent on just one person and an antiquated
'patches' system could definitely improve things.

Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
Great minds have purposes, others have wishes. Little minds are tamed and
subdued by misfortune; but great minds rise above them.
-- Washington Irving

Max Roeleveld

unread,
Feb 24, 2014, 5:22:05 AM2/24/14
to vim...@googlegroups.com, li...@majutsushi.net
On Monday, February 24, 2014 10:29:38 AM UTC+1, Jan Larres wrote:

> So in
> addition to the refactoring I think that a more flexible development
> model that is not dependent on just one person and an antiquated
> 'patches' system could definitely improve things.

That, however, is something that could be done without changing a line of code, right?

Marc Weber

unread,
Feb 24, 2014, 7:29:37 AM2/24/14
to vim_dev
Vundle vs Vam vs .. issues showed that users don't need 100%
satisfaction in all cases - projects can still be successful.

Eg I mean: Vundle depends on vim-scripts.org - and vim-scripts org maps
scripts from www.vim.org to urls by title - and some title occur more
than once. Thus there is a chance that you cannot install what you want.
(There have been 1-2 issues) - still Vundle hase incredibly many users.

So the important question is: Which regressions will be critical to
masses and which won't? Time will tell. I'm happy that this "experiment"
is taking place. If you don't try to succeed - you failed from the
beginning IMHO.

Marc Weber

Diego Viola

unread,
Feb 24, 2014, 11:01:51 AM2/24/14
to vim...@googlegroups.com
I don't understand, Bram says "It's much better to improve what we have." which
is good and reasonable to me. I agree with this.

But then we have people like Thiago de Arruda (aka tarruda) who have worked
very hard on multithreading support for Vim, and his patches didn't make it
into mainline Vim.

So how can we "improve what we have" when 99% of the patches are ignored or
rejected according to most developers?

Sorry, I do have great respect for Bram Moolenaar and his work, I just don't
understand this development model at all.

Perhaps the fork could have been avoided if the development model was more
reasonable? I don't know.

Diego

Peter Aronoff

unread,
Feb 24, 2014, 11:34:30 AM2/24/14
to vim...@googlegroups.com
On Mon Feb 02/24/14 at 8:01, Diego Viola wrote:
> But then we have people like Thiago de Arruda (aka tarruda) who have
> worked very hard on multithreading support for Vim, and his patches
> didn't make it into mainline Vim.
>
> So how can we "improve what we have" when 99% of the patches are ignored
> or rejected according to most developers?

I've only been following this list for about a year now, but I can already
see that your last paragraph seems unnecessarily negative and the numbers
seem pulled from thin air. *99%* of patches are rejected? Really? And
*according to most developers*? Really?

More realism would help, I think.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Diego Viola

unread,
Feb 24, 2014, 11:36:29 AM2/24/14
to vim...@googlegroups.com
OK I'm sorry about that, that was an exaggeration.

Sorry.

LCD 47

unread,
Feb 24, 2014, 4:51:55 PM2/24/14
to vim...@googlegroups.com
On 24 February 2014, Diego Viola <diego...@gmail.com> wrote:
> I don't understand, Bram says "It's much better to improve what we
> have." which is good and reasonable to me. I agree with this.
>
> But then we have people like Thiago de Arruda (aka tarruda) who have
> worked very hard on multithreading support for Vim, and his patches
> didn't make it into mainline Vim.
>
> So how can we "improve what we have" when 99% of the patches are
> ignored or rejected according to most developers?

I believe you miss the big picture here. At this point, virtually
nobody aside from Bram understands the code well enough to make "big"
changes. The other "main" developers are just people that know enough
about the code to scratch their own itches. These people post patches
occasionally (and Bram usually includes their patches), but their
interest is generally limited to particular pieces of Vim, and don't
have either the motivation or the resources to look anywhere else.

As a result, what happens when an "outsider" posts something as far
reaching as the recent timeout / async patch, or the multithreading
patch, is that Bram is reluctant to write an in-depth analysis (he has
been at this for 20+ years, he has a job, a life, and he already has his
hands full just from maintaining Vim as it is), and nobody else really
feels qualified to post a meaningful answer. The only somewhat informed
feedback the author receives is then a few vague and / or opinionated
rants that rarely go beyond pointing out the obvious. Then the author
concludes that nobody cares, feels offended, takes it personally, and
posts frustrated calls to arms on YC. There, they manage to receive a
deluge of way more opinionated, way less informed rants about anything
and everything Vim except the actual patch, and things slowly loop back
to the statu quo ante.

On the other hand, most of these far reaching "outsider" patches
are, actually, less than perfect. That's to be expected too, partly
because what they are trying to do is objectively hard (if it weren't,
it would have been done long ago), and partly because the authors don't
read the code end to end before starting to write their patch, to make
sure their changes doesn't interact badly with other parts of Vim.
That's actually the kind of feedback they would expect from the list.
But, as I explained above, this doesn't happen. Rinse and repeat.

> Sorry, I do have great respect for Bram Moolenaar and his work, I just
> don't understand this development model at all.
>
> Perhaps the fork could have been avoided if the development model was
> more reasonable? I don't know.

If you think Bram should just merge all these crowd-acclaimed
patches, no question asked, you'd be wrong too (IMO, of course). See
f.i. what other people have to say about Vim, even without experimental
patches:

https://news.ycombinator.com/item?id=6668453

As I see it (and for what it's still worth), the way forward is
not to lower the standards for accepting patches. It isn't to rewrite
Vim from scratch in Haskell, Javascript, Rust, Go, or whatever other
language of the day. It isn't to refactor it to use libuv, or other
revolutionary library of the day. And it certainly isn't to compile yet
another list of flaws, or another wish list.

In my opinion the way forward is for enough people to start reading
the code, patiently and diligently, in their own rhythm. Once there is
a critical mass of developers who actually understand the code, and see
it as just old, rather than terrible or evil, we might see progress.

/lcd

Marc Weber

unread,
Feb 24, 2014, 5:47:48 PM2/24/14
to vim_dev
> In my opinion the way forward is for enough people to start reading
> the code, patiently and diligently, in their own rhythm. Once there is
> a critical mass of developers who actually understand the code,
Which will never happen because those people today who want to code
might no longer choose C for good reasons (for such a large project)

And more than that - starting with Vim',s code base is a huge
undertaking. Rule of thumb: Reviewing code takes 50% of the time it took
the author to write !

(Which means a lot of time -> nobody can do this in his/her spare time
IMHO - without sacrifying family personal goals and the like)

Thus its even more important that we try to turn Vim into kind of
"business" model - because "specialization" is the engine of todays
world - even more for complex software like Vim.

Libraries such as libuv just do that: they forward the task of having
unique interfaces to a central place - and often its a good idea.

I asked in 2010 whether Bram would be willing to spend more time on Vim
if he got payed (didn't get a reply that time):
reference: https://groups.google.com/forum/#!topic/vim_dev/43b6gsHh4Ok
If he had I would have tried starting crowd funding campaigns that time.

And that's why I hope that tarruda turns this into a business (for
everyone) - so that he (and others) can keep working on their code
plugins / parts of vim.

Whatever the outcome will be - we'll be smarter afterwards :)

What did I learn from the mailinglist recently?
The more the merrier. The usual problem is that people have to give up
to make a living (eg ensime project), quote from its readme:

"A quick note on status: Events in my life have conspired to give me
less free time to work on ENSIME."

And this is happening to a lot of open source projects (wasting a lot of
time of those people who invested some time on such - eg my writing the
first ensime frontend for Vim - which I had to give up for time/money
reasons, too). What tarruda is doing is the right thing - and I hope
that he creates kind of market place for proposals/ people joining them
(offering funding) / and programmers saying "for this money I'll get the
job done".

Then we'll have a healthy community (IMHO).
Again - you are free to think differently.

I'm pretty sure that tarruda will break a lot of things (by accident).
But there is still a chance for paying off in the long run.

Marc Weber

Jan Larres

unread,
Feb 24, 2014, 6:28:06 PM2/24/14
to vim...@googlegroups.com
LCD 47 <lcd...@gmail.com>:
> In my opinion the way forward is for enough people to start reading
> the code, patiently and diligently, in their own rhythm. Once there is
> a critical mass of developers who actually understand the code, and see
> it as just old, rather than terrible or evil, we might see progress.

This sounds like a good idea in theory, but I don't think Vim's current
development model lends itself to that. How do you determine if someome
"actually understands" the code? By submitting refactoring patches, or
enough patches in general? But several people already have submitted
many patches, and many of the needed refactorings, like getting rid of
global variables, actually require bigger changes, and Bram would
probably be (understandably) reluctant to include them right away. The
result of that would be that they just sit in the todo list like so many
other patches.

I think the best solution to this would be to get rid of the "one branch
with patches" model and instead have at least a stable and a development
branch, with more people than just Bram being able to commit to the
development branch. Bigger changes like refactorings or the new regex
engine even could get their own feature branch. That's what VCSs like
Mercurial are good at, but it's not being made use of at the moment.
With this model the stable branch would be used for releases and by
people who care most about stability, and people who are willing to try
out new features could use the development branch(es). Unless they
disable swap files that shouldn't even be a big risk in general. I'm
sure this approach would also motivate more people to contribute when
they don't feel like it's a gamble whether their changes will ever
actually make it in.

-Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
If you give me six lines written by the hand of the most honest of men, I
will find something in them which will hang him.
-- Cardinal De Richelieu

LCD 47

unread,
Feb 24, 2014, 6:39:18 PM2/24/14
to vim_dev
On 24 February 2014, Marc Weber <marco-...@gmx.de> wrote:
[...]
> Thus its even more important that we try to turn Vim into kind of
> "business" model - because "specialization" is the engine of todays
> world - even more for complex software like Vim.

What I'm saying is, it takes _knowledge_ to move forward. Now,
some amount of knowledge can be bought (making a business out of
your project, hiring people etc.), some other amount can be borrowed
(using frameworks, libraries, and the like), and yet some amount
can be obtained as a gift (the open source way). However, in my
experience most of it has to be earned. It is seldom if ever achieved
by spontaneous generation. :)

http://en.wikipedia.org/wiki/Spontaneous_generation

[...]
> What tarruda is doing is the right thing
[...]

I actually like this project too. I'm just pointing out it's better
to think first and then do the work, rather than do the work then find
out you should have spent more time thinking first. *shrug*

/lcd

LCD 47

unread,
Feb 24, 2014, 7:01:06 PM2/24/14
to vim...@googlegroups.com
On 25 February 2014, Jan Larres <li...@majutsushi.net> wrote:
> LCD 47 <lcd...@gmail.com>:
> > In my opinion the way forward is for enough people to start
> > reading the code, patiently and diligently, in their own rhythm.
> > Once there is a critical mass of developers who actually understand
> > the code, and see it as just old, rather than terrible or evil, we
> > might see progress.
>
> This sounds like a good idea in theory, but I don't think Vim's
> current development model lends itself to that. How do you determine
> if someome "actually understands" the code?
[...]

You don't. It isn't relevant, the goal is not to give merit bages,
but to actually evolve as a group. From this point of view, the process
(how the patches are submitted, who gets to say what goes in and when,
and so on) are just details.

/lcd

Jan Larres

unread,
Feb 24, 2014, 7:24:30 PM2/24/14
to vim...@googlegroups.com
LCD 47 <lcd...@gmail.com>:
But it's not just details. That's the point. A flexible and transparent
development model (transparent as in "people will be able to gauge the
success of inclusion of their patches, or at least will receive official
feedback in a reasonable amount of time") is crucial for motivating
potential contributors. How would your suggested evolving concretely
improve things otherwise? People will just magically contribute better
patches at some point? Even if that were to happen that would still
require Bram to spend time reviewing all of them, so we're back to
square one as that is exactly what he doesn't have enough time to do.

Like I said, it's a good idea in theory but I don't think it would work
out without any other changes. If it could work out something like that
would most likely have already happened by now given how long Vim has
been around.

-Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
Technological progress has merely provided us with more efficient means for
going backwards.
-- Aldous Huxley

LCD 47

unread,
Feb 25, 2014, 1:11:04 AM2/25/14
to vim...@googlegroups.com
On 25 February 2014, Jan Larres <li...@majutsushi.net> wrote:
> LCD 47 <lcd...@gmail.com>:
> > On 25 February 2014, Jan Larres <li...@majutsushi.net> wrote:
> >> LCD 47 <lcd...@gmail.com>:
> >>> In my opinion the way forward is for enough people to
> >>> start reading the code, patiently and diligently, in their own
> >>> rhythm. Once there is a critical mass of developers who actually
> >>> understand the code, and see it as just old, rather than terrible
> >>> or evil, we might see progress.
> >>
> >> This sounds like a good idea in theory, but I don't think Vim's
> >> current development model lends itself to that. How do you
> >> determine if someome "actually understands" the code?
> > [...]
> >
> > You don't. It isn't relevant, the goal is not to give merit
> > bages, but to actually evolve as a group. From this point of view,
> > the process (how the patches are submitted, who gets to say what
> > goes in and when, and so on) are just details.
>
> But it's not just details. That's the point. A flexible and
> transparent development model (transparent as in "people will be able
> to gauge the success of inclusion of their patches, or at least will
> receive official feedback in a reasonable amount of time") is crucial
> for motivating potential contributors. How would your suggested
> evolving concretely improve things otherwise? People will just
> magically contribute better patches at some point?
[...]

I was actually pointing the other direction. If I were more
knowledgeable of the code, I would be more inclined and / or able to
give meaningful feedback when something like the multithreading patch is
posted, rather than shrug it off as outside my comfort zone. Apply that
to a number of regulars, and you'd get an actually functioning group.
It's only at that point that it would make sense to start talking about
improving the process, fork the project, or whatever else you see fit.

/lcd

Jan Larres

unread,
Feb 25, 2014, 5:53:31 AM2/25/14
to vim...@googlegroups.com
The problem is that you need a motivation for investing time in getting
more familiar with the code base. Only very few people would read the
code just for fun, in the majority of cases reading code is motivated by
wanting to make changes to it. But if the chance of your contributions
even getting looked at is very hit-and-miss then that will demotivate
even the most engaged person at some point, and they will stop investing
time into the code and therefore be lost to the group of people who
would be able to give meaningful feedback. One good example apart from
the async patch you mentioned that comes to mind is the patch to
introduce delete/yank autocommands, which was posted over two years ago
and was quite simple, but still hasn't been integrated. The original
author has even switched away from Vim now, how much this issue was a
part of that I don't know.

-Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
Faith. n: Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.
-- Ambrose Bierce, "The Devil's Dictionary"

Marc Weber

unread,
Feb 25, 2014, 7:08:54 AM2/25/14
to vim_dev
Excerpts from LCD 47's message of Mon Feb 24 23:39:18 +0000 2014:
> I actually like this project too. I'm just pointing out it's better
> to think first and then do the work, rather than do the work then find
> out you should have spent more time thinking first. *shrug*

If you have suggestions (what to think about first) create issues:
https://github.com/neovim/neovim/issues/new

We could try to focus on this view:
- There is a programmer who got payed to work on Vim
- He will work on Vim
- Thus there is high chance that soon there will be two people who can
review patches in the future
- we still can influence what tarruda does - so maybe we should try to
do so that his changes can be merged back, too

Thus the vim community has two options
- ignore
- try to collaborate and emphasize on important things

Maybe there is a chance to turn this into success for everybody.

I'm pretty sure that he'll listen to comments.

Important choices: Should neovim build up its own community (mailinglist
etc) - or should they be allowed to use vim-dev and vim-use.

There is a mailinglist which got added to the README recently.
https://groups.google.com/forum/#!forum/neovim

Its time to think about this *now*. If there are people on the
mailinglist who think they know better than tarruda does - they should
talk to him. He is listening.

again - my 2 cents

Marc Weber
Reply all
Reply to author
Forward
0 new messages