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

[nhaehnle]

The code if fill of typedefs for AMIGA and OS/2.

There's nothing wrong with that as long as those typedefs are properly isolated in some platform-specific header files.

It's natural to have an initial feeling of being overwhelmed by that kind of stuff. However, it often turns out that there's nothing to gain from removing that stuff.

The only real cost is when people expect a platform to work, but nobody from that platform is willing to put in the testing effort.

[ggreer]

Have you looked at the Vim source? There are a few things in platform-specific headers, but most ifdefs are scattered in actual code. There are even ifdefs in the middle of control flow statements. For example, in RealWaitForChar(): https://github.com/b4winckler/macvim/blob/master/src/os_unix...

That function is over 400 lines and has over 50 ifdefs. What does it do? It waits for any key to be pressed. Unfortunately, Vim is single-threaded and synchronously character-driven, so it has to try and process some autocmds and other events in the same loop.

Oh and the wait loop uses gettimeofday(), which is not monotonic.

To get another taste of Vim's source, take a look at https://github.com/b4winckler/macvim/blob/master/src/eval.c (Warning, may crash your browser.) That file is 25,000 lines and checks hundreds of different ifdefs.

[tokenrove]

If that example (eval.c) is supposed to be bad, I don't think there's a strong case here. It looks like lots of older Unix/BSD code, and most of the ifdefs are feature-related, rather than platform hacks; some of the functions are a bit long, but that's typical in older C code.

I've never read the vim code before and I was surprised how cleanly written and well-commented it is, given my expectations set by this thread.

[kzrdude]

I love that if whose condition stretches over 15 lines with inline ifdefs, and then the body of the conditional is just one line without surrounding braces..

[dllthomas]

Inedibly?

[aidos]

I'm not sure if you read the original proposal - but it's not a rewrite. It has specific targeted goals in mind to refactor the code to make it easier to develop with (and better abstracted, isolated, and so it can handle async comms for the interface and plugins).

It will drop support for lots of legacy systems. That will allow simplification of the code - at the cost of those on amigas.

I love vim. I use it for all my development. I've only been using it for a couple of years though and I can see the warts that are being addressed. They were fairly evident upon joining the ecosystem and I don't think "it's too hard to change" is a viable long term strategy.

I would absolutely love neovim to succeed - and I think that something like it is essential if vim is to have any place in the future.

[jamesrcole]

> ...code base full of weird special cases ... _often_ turns out that all this cruft is there for a reason. It's essential complexity... (my emphasis)

If it's often, then it's not always, which means that in some cases it could be done better. Is Vim one of those cases? I don't know, but you don't give any reason to suggest that it isn't.