
Bram Moolenaar responds to Neovim - dviola
https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8
======
mekoka
_Total refactoring is not a solution._

To Diego: Prove him wrong. I suspect that Bram has been maintaining the code
base for so long, that he might need a bit more than a mere message to warm
him up to the idea of a refactoring to the scale that you're undertaking.
Also, you might not be the first person to contact him with such a proposal. I
wonder how long it took for others before they gave up. Build something
tangible and contact him again later with proof of concept, something that
would make this more than just a fleeting dream.

To people questioning Bram's position: You need to look a bit further than
your nose. The fact that you want to create plugins or extensions does not put
you in the mainstream as a Vim user. It's an extremely popular editor of
almost religious proportion, with lots of existing plugins and extensions. So
we know that people use it and making plugins is possible. With all of its
annoyances it gets the majority of the job done for most users. One can't just
wake up one day and say that they'll change things, not even Bram at this
point.

The most desirable outcome in my opinion would be to have Neovim be a
continuation of Vim (Vim 10.0?) rather than just another fork, and for that,
having Bram on board would be a boon. His longevity as a maintainer is
impressive.

~~~
gradstudent
Good points but I'm not convinced there exists a compelling reason to fork
vim. From a user perspective there are no points of differentiation between
NeoVim and vim. As an outsider looking in, it appears to me that NeoVim exists
only to scratch the itch of some developers writing vim extensions.

Is that reason enough to exist? Maybe. But what's the long-term aim here?
Without a strong point of differentiation to attract users and thus developers
NeoVim will be left forever playing catchup with Bram's original creation --
constantly rewriting new features to remain relevant and forever fixing both
old vim bugs and new NeoVim-specific bugs.

~~~
njharman
"From a user perspective there are no points of differentiation between NeoVim
and vim."

This is shallow and short-sided opinion. If neovim achieves goal of "easier to
maintain codebase" then it will have much faster feature development, bug
fixing, and extension development. All extremely user facing and exciting.

~~~
gradstudent
> This is shallow and short-sided opinion. If neovim achieves goal of "easier
> to maintain codebase" then it will have much faster feature development, bug
> fixing, and extension development. All extremely user facing and exciting.

I think this is a bit naive. There's no plan of any kind laid out for NeoVim,
not even a goal against which progress can be concretely measured. New and
compelling features must be well thought-out, well designed and well executed;
they don't just fall out of the sky as a consequence of "easier to maintain
code".

------
CJefferson
To be fair to the authors of neovim, there were patches they wrote and
submitted to vim, which added exciting new features I would like, which were
rejected.

People who basically want him to never change (and that is fine) can be happy
with mainline. There are others who would like to see some significant
updates, particularly allowing better threading support.

~~~
shmageggy
What were the features they submitted? Stuff that's mentioned on the github
page or something else?

~~~
btipling
At Floobits we tried to submit set_timeout/async stuff, and couldn't get
anywhere with Bram. Months of work wasted.

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

~~~
teacup50
Your patches were broken. People spent plenty of time trying to help you fix
them.

Your response is to tell the Internet that Vim is wrong for not accepting
broken patches?

~~~
Jasber
Did you read the same thread I did? Floobits addressed all the issues.

It came down to a fundamental design decision—and after months of hard work,
they got a non-answer.

~~~
ampersandy
Bram's last post was 10/21/13, and a month later Bjorn confirmed in his fork
that he could reliably freeze VIM and had segfaults that he had yet to fix.
The final word seemed to be:

"There are enough vim users out there (myself among them) to warrant
supporting a fork for as long as we're around. We'll try to keep it up to date
with the latest changes."

I don't think anyone should expect Bram to chase them down for updates to the
patch. Reading through the discussion, it seems clear to me that while good-
natured, the feature was not ready to be merged into VIM.

~~~
btipling
We actually continued to work on the fork until it was clear Bram wouldn't be
responsive to any more changes. Once it became clear he wouldn't accept the
patch we stopped wasting more time as we are trying to create a viable
business. We weren't going to sink our startup for the sake of vim, as much as
I love the editor. We spent a long time, it was a frustrating experience, so
yes we tell the internet when it comes up. Any of the freezes we found we
would have loved to patch back into vim had this gone differently, and it
would have been a lot of work.

~~~
teacup50
My only takeaway from the thread was that you approached the process of patch
review begrudgingly, and seemed to assume that everyone should
understand/appreciate your node-derived vocabulary and design.

Each iteration of the patch was provided with a whine about whether it was
ready for inclusion _yet_ ... when the reality is, that as the patch author,
it's _your_ job to make sure there aren't more bugs and the patch is ready for
inclusion.

Every time someone found another issue was a red flag to any sane maintainer
that your patch wasn't ready for inclusion. Every time you whined about having
to iterate, you made it clear that you couldn't be trusted to have written
something stable and maintainable.

If you can't deal with working on mature software, stick to startup code.

~~~
btipling
Nothing you've said is true.

~~~
teacup50
And nothing you've said is true. Fortunately everyone can compare our
subjective realities against the actual thread.

------
sramsay
Perhaps this was mentioned the other day, but Neovim did make me think of this
old chestnut from Joel Spolsky:

[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

I realize Neovim is being characterized as an "aggressive refactor," but I'm
sure that's the way Netscape thought of it as well.

tl;dr Things you should never do: rewrite the code from scratch.

~~~
haberman
With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang
(NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself
(NeoVi/Elvis/Stevie/etc).

~~~
raverbashing
Huummmmm no

Neovim is being sold as a VIM refactor, but apparently with no new
functionality

 _Very_ different from Linux (had an aim of being a playground for new
features), tmux is different from screen as Clang is different from GCC,
Subversion is a totally different beast from CVS

~~~
haberman
> Neovim is being sold as a VIM refactor, but apparently with no new
> functionality

Where did you get that idea? When I read the project page
([https://github.com/neovim/neovim](https://github.com/neovim/neovim)), two of
the explicit goals are:

"Enable the implementation of new/modern user interfaces without any
modifications to the core source.

"Improve the extensibility power with a new plugin architecture based on
coprocesses. Plugins will be written in any programming language without any
explicit support from the editor. "

It is exactly designed to be a playground for new features, but with the goal
of them not having to be in the core.

~~~
pit
The original mailing list message says:

"There's a new project that is called Neovim that seeks to refactor and
modernize the codebase"

~~~
zimbatm
That's the necessary step 1 to allow further enhancements

------
bachback
well of course. Vi was specifically written by Bill Joy to optimize for every
character, see

[http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...](http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/)

And there is no reason we could ever improve on that 35 years later. we need
those optimizations...

"It took a long time. It was really hard to do because you've got to remember
that I was trying to make it usable over a 300 baud modem. That's also the
reason you have all these funny commands. It just barely worked to use a
screen editor over a modem. It was just barely fast enough. A 1200 baud modem
was an upgrade. 1200 baud now is pretty slow.

9600 baud is faster than you can read. 1200 baud is way slower. So the editor
was optimized so that you could edit and feel productive when it was painting
slower than you could think. Now that computers are so much faster than you
can think, nobody understands this anymore. "

~~~
perlgeek
Whenever I use vim through a lagging SSH connection, I'm very happy that it's
still usable (at least more so than other editors).

~~~
mst
If you can stand the fact that it's only got the original feature set, ex-
vi.sf.net provides a version of the original vi that runs on modern unices.

I use it on a daily basis and have found that it copes with conference
wireless far better than vim does.

------
hglaser
Why aren't there other vim committers?

Bram's conservatism makes perfect sense for someone who has to maintain this
huge, consequential, intimidating codebase. Why hasn't he gotten some help?

~~~
kamaal
Big old code bases, have a lot of what I call as 'tribal knowledge' associated
with them. People go out, and do experiments only to burn their hands. Over
years, the old maintainers generally accumulate a lot of ideas and 'tribal
knowledge' to know why 'pie in the sky' ideas won't work.

Nevertheless, people still try. A lot of them fail, a few succeed.

The vim code base is around 300K lines of C code. I'm sure its nothing like
Java where 90% of the code is get/set methods, high level delegating classes
and exception handling code. 300K lines of code which does the actual work is
simply too much code. And one should exercise great caution while dealing with
it. Regression is just one thing, I'm sure there are a lot of places in the
code which can silently break things you can't detect only to pop up in some
strange case in the wild.

~~~
chris_wot
I can't speak for vim, but the following smacks of code that _needs_ a
refactor:

 _300K lines of code which does the actual work is simply too much code. And
one should exercise great caution while dealing with it. Regression is just
one thing, I 'm sure there are a lot of places in the code which can silently
break things you can't detect only to pop up in some strange case in the
wild._

------
ayosec
This reminds me to the origin of Inkscape, as a fork from Sodipodi. The (only)
Sodipodi committer didn't want too many patches, and he wanted to stay with C
(no C++ code).

Some people forked Sodipodi, and created Inkscape. I can remember that one of
their first tasks was to make the code compatible with a C++ compiler.

Nowadays, Inkscape is a very good tool, and I hope that Neovim has a great
success too.

------
kzrdude
Vim is not a healthy project. Example: They support transparent encryption for
documents, but refuse to address or document the shortcomings of their
implementation. It's of course a fully custom implementation of a half-
homerolled protocol.

Main flaws: Apart from implementation issues, non-authenticated encryption
susceptible to bitflipping.

------
perlgeek
It's very easy to look at code base full of weird special cases and think
"this could be such much easier if I started from scratch", but in the end if
often turns out that all this cruft is there for a reason. It's essential
complexity that you wrongly identified as artificial complexity. And the
rewrite ends up being much more work than originally anticipated.

I don't think there's a way to learn that except by making the same mistake
yourself, possibly more than once.

~~~
CJefferson
That is an overly simplistic viewpoint. Vim is written in an inedibly old
style of C which is not taught anymore, or used by most people. The code if
fill of typedefs for AMIGA and OS/2\. Useful to a small number of people
certainly, but making progression harder too.

This is not a total rewrite, it is a massive overdue refactoring.

~~~
perlgeek
> The code if fill of typedefs for AMIGA and OS/2\. Useful to a small number
> of people certainly, but making progression harder too.

Sounds like the code of pretty much every non-trivial C program that is meant
to run of many platforms, not just the five or ten most popular ones.

I'm not saying that this is a good thing, just that I don't know any good
alternatives that don't sacrifice compatibility with lots of platforms.

~~~
kzrdude
It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a
real nightmare.

The very first commit in neovim includes this log:

    
    
         - Process files through unifdef to remove tons of FEAT_* macros

~~~
teacup50
Which is exactly the sort of pointless "refactoring" that someone does instead
of actual refactoring.

It also makes merging back to vim difficult to impossible.

Expect to see 'neovim' development dissipate rapidly.

------
ageofwant
My $20 is totally worth the "risk". Here's some dude from Brazil, that has at
least some demonstrable skill, willing to take a month and have a go at
improving a tool I use every day. For the price of four coffees.

As for Bram, he can, and most likely will continue his good work on vim. I am
kind of disappointed that he is not more supported of this effort though.

------
typicalbender
That seems like a fair response. I tend to agree that sweeping refactorings
tend to take a lot of time and it's better to break off small bite size
pieces. That being said I really like some of the proposed improvements into
vim. I wonder if a similar approach could be taken as when vi was improved to
create vim, or perhaps that's what added all the complexity Neovim is trying
to solve.

------
jbranchaud
_As vi was a popular editor amongst programmers and system administrators,
there initially was doubt whether Bram 's 'improved' version could achieve the
quality and fan following of the original. But since its first release for
Unix systems in 1992, Vim has effectively eclipsed the original Vi, having won
several awards[3] and has been referred to as one of the most popular text
editors._

\- Excerpt from
[http://en.wikipedia.org/wiki/Bram_Moolenaar](http://en.wikipedia.org/wiki/Bram_Moolenaar)

------
jballanc
The old Unix ways are dying...

Or, at least, I think that's the best way to summarize the essential
miscommunication between these two camps. Vim is, in the spirit of Unix, a
single purpose tool: it edits text. Why would it need threading? async?
background jobs? You can't type in two places at once, right?

NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the
ability to do background compilation/syntax checking, a bit of debugging here,
some REPL-ish things there. For that you need a better async story, better
process control, etc.

So, in the end, I don't actually see a problem here. Vim will cater to one
audience, NeoVim to another. For my money (or donation to Uganda), I'm happy
using tmux splits, sending text between vim windows and REPL windows, and
keeping Vim primarily as a text editor with syntax highlighting. I would
appreciate if _some_ events could be backgrounded (e.g. syntax check on file
save), but I don't think this needs a complete refactor.

~~~
ansible
In some ways, neovim keeps to the Unix spirit better than vim. People already
use vim as an IDE, but it doesn't work well in many cases. And the alternate
user interfaces are not as good as they could be.

If you've got a clean separation between the editing engine and the rest of
the IDE suite of processes, that is the Unix way in my view.

------
edanm
I get the idea that Bram thinks it's going to be more of a rewrite than _I_
think it's going to be. As in, I assumed that neovim would not be a complete
rewrite or something, but more targeted refactorings.

Of course, Bram knows the codebase and I don't, and I may well have
misunderstood the neovim plan, so I'm not sure which of us understands.

------
z3phyr
Abrash wrote in his graphics programming black book, and I quote, Carmack's
law ->

"I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code
entropy. If you have a new fundamental assumption, throw away your old code
and rewrite it from scratch. Incremental patching and modifying seems easier
at first, and is the normal course of things in software development, but ends
up being much harder and producing bulkier, markedly inferior code in the long
run, as we’ll see when we discuss the net code for QuakeWorld. It may seem
safer to modify working code, but the nastiest bugs arise from unexpected side
effects and incorrect assumptions, which almost always arise in patched-over
code, not in code designed from the ground up. Do the hard work up front to
make your code simple, elegant, great—and just plain right—and it’ll pay off
many times over in the long run."

~~~
ksk
If you watch any of Carmack's recent keynotes you'll see hes advocating doing
the opposite now. Whats changed is the multi million dollar risk profile
associated with modern game releases, the huge increases in the sizes of the
teams, the large scale complexity of modern AAA code-bases, etc. And also the
fact that most games now are data-dominant rather than being sold entirely on
some new game-engine feature(s).

------
ChuckMcM
Every 10 years or so I think some energetic programmers should set about
writing God's Own Text Editor. There have been a lot of really useful
technologies that have come from those efforts, whether it was EMACs, Gosling
EMACs, vi, vim, pfe, visual slick edit, sublime text, or even wordpad. An
editor is a fairly complete system, well within the capabilities of a single
motivated individual, and like cocktail gowns entirely fashion/taste driven.

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

That may be a problem for vim but not for neovim. Neovim doesn't have a legacy
user base, they can focus on the currently used systems.

------
tambourine_man
The project has already surpassed its requested value in the first 48hs. The
enthusiasm reminds me of git-annex.

I really love this business model, the developer works on something he is
passionate about, we can support the project and influence its future, all
while strengthening the community around it.

------
chimeracoder
He's right. With every project, there's a tradeoff between achieving the goals
of the project and maintaining compatibility with existing systems.

As a Go programmer, I feel a bit sad/ashamed to be saying this, but look at
Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS,
because the latter was "good enough", and was already more widely supported
and used.

Plan 9 vs. Unix is a very different comparison than Vim vs. Neovim, and there
are a lot of other factors at play, but the same principle actually holds.
Improving or extending an existing system in a compatible way is a lot easier
than trying to establish mindshare with a completely new tool.

The tradeoff is that extending existing systems leads to cruft and bloat. So
_if_ you can establish mindshare with a new tool, you have an opportunity to
make a much more elegant one. But that's a big "if".

 _EDIT_ : I think a better analogy may be an attempt to refactor the Linux
kernel into a microkernel. I'd certainly love it if this magically happened -
microkernels are much easier to work with, and much more elegant. But it'd be
hard to make the case that that'd be a worthwhile endeavor at this point,
given the costs of doing so.

~~~
mjn
I think the other factors in play are the dominant ones in the Unix/Plan9
issue, though. The original "upstream" of Unix was Research Unix, the stuff
the Bell Labs researchers were working on. V1 came out in 1971. But V7,
released in 1979, basically got forked into a bunch of commercial Unixes (and
indirectly, some free ones via the BSDs). Research Unix V8, V9, and V10 got
virtually no uptake, despite being incremental evolutions of the original
upstream, due to a mixture of inertia and licensing restrictions from AT&T.
Instead, different incremental evolutions of V7, developed by other developers
outside Bell Labs, became the dominant strains of Unix.

Plan9 was a pretty significant departure from Research Unix V7, but not _as_
significant a change compared to V10... which didn't matter because nobody
outside Bell Labs was using V8/9/10 anyway, since everyone was working on
various forks of V7 (BSD, SunOS/Solaris, Xenix, etc.).

~~~
4ad
I agree Plan 9 is not a good example in this story. Plan 9 didn't failed
because of the problems associated with a re-write as described in Joel's
post, but because of political and social issues.

> Research Unix V8, V9, and V10 got virtually no uptake, despite being
> incremental evolutions of the original upstream, due to a mixture of inertia
> and licensing restrictions from AT&T.

I'm not sure what you mean by inertia. v8-v10 were not widely released to
avoid another BSD incident.

v8-v10 were 4.3BSD derivatives, so I'm not sure I'd call them incremental
evolutions on the original upstream. They removed and/or reworked all the new
BSD stuff though, and the basic userland was very custom. Some of it survives
(in some form) in Plan 9.

------
sigzero
I won't move off of Vim personally. I don't push it really as I use a pretty
stock setup. However, good luck to the neovim devs, it will be cool to watch.

------
keyle
Sorry to point out to the ironic here. But his signature includes the link to
a "new programming language". And it reads much like "Neo-C".

------
chris_wot
Refactoring is _hard_. I'm learning this with delving into the LibreOffice
codebase. It's got a lot of issues - about 25 years of accreted code and
design decisions that need unpicking, tangled code that needs refactoring,
etc.

However, it's sure easier to refactor than start from scratch! At least LO has
a working product. Best of luck to the Neovim guys :-)

------
codelap
What would you call going from vi to vim? Regardless, anything that fixes the
mess that is vimscript gets a thumbs up from me.

------
lukasm
Am I the only one thinking why C?

~~~
pstuart
Nope.
[http://talks.golang.org/2014/go1.3.slide#23](http://talks.golang.org/2014/go1.3.slide#23)

------
thetxef
maybe if Bram even commented on the two patches that Thiago had posted, things
could have been different.

All Thiago got was: being ignored, one of the worst ways of disdain. Not just
even a 'thanks but not interested'.

Other two guys who tried to provide patches to be merged on the same area also
suffered from being mostly ignored (he replied to them but just once I think).

------
_pmf_
Streamlining and simplifying a code base by introducing JSON-RPC for internal
API? Success is practically guaranteed!

------
bakul
I haven't looked at vim code in ages but if it is really 300K lines of code, I
wouldn't refactor it in any major way. If I absolutely wanted to scratch that
particular itch, I'd rewrite it from scratch. In another language (not C or
C++). And structure it differently.

------
dylnclrk
Was Vim a complete rewrite of Vi?

~~~
maxk42
Lots of things were a complete rewrite of vi. Vi was a complete rewrite of ex.
ex was a rewrite of em, which was in turn a rewrite of ed, which was a rewrite
of qed.

Trying to rewrite vim is the wrong approach. Trying to replace it in a
backward-compatible way, the way vim did to vi might received a lot better.

~~~
Narishma
Good thing then that they aren't rewriting vim.

------
general_failure
Refactoring is not a big deal. In fact I don't even want total compatible with
vim.

------
est
Total refactoring without regression is rare. Especially in the wild.

------
farginay
Clang v. GCC all over again?

------
jijji
1\. make kickstarter campaign to "revolutionize" open source project vim.

2\. :%s/vim/neovim/g

3\. profit!?!?!?!?!?

------
tinco
Well that does it I'd say. With such a negative attitude, who wants him on the
team anyway? What the advantages are? They're clearly laid out in the project.

Seriously, screw that guy.

edit: Yes I know who 'that guy' is and it's great he's been working on Vim for
all these years, but he certainly has his head up his ass if he thinks Vim
users would not benefit from some big refactorings, a more accessible code
base and some dropped platforms. If all those Amiga programmers love Vim so
much, why would they be disappointed with an eternal Vim7.4?

It's not too late for Vim to lose the editor wars.

~~~
aeonsky
I still have yet to see these concrete user benefits.

~~~
svalorzen
The benefit is indirect rather than direct, as in the user benefits from the
increased availability of plugins/guis since they would be easier to create.
Also vim lacks lots of very simple but essential features of modern code
editors simply because it lacks the graphical capabilities to do so (an
example would be displaying the documentation of some method you are
autocompleting, something which I have never seen in vim and which I actually
believe is impossible).

~~~
psquid
> an example would be displaying the documentation of some method you are
> autocompleting, something which I have never seen in vim and which I
> actually believe is impossible

For python at least, having 'preview' as part of your completeopt has it
display the docstring of what you're completing. And :h completeopt suggests
that's intended behaviour for all types of completion (where it makes sense),
too.

~~~
fmoralesc
Yes, but currently retrieving that info is done synchronously, so it might
slow down things. Under neovim's model, this can be done more efficiently.

