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.

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.

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.

http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g...

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

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

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.

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

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

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.

- Excerpt from http://en.wikipedia.org/wiki/Bram_Moolenaar

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.

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.

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

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.

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.

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.

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

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

Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :)

But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.

I can clearly see the benefit of this old wisdom under context of limited resource and limited time, esp. in a commercial company.

However, as an experimental, personal(?), non-profit, free/open-source project, I do think neovim has value in its own right:

1. It won't affect any existing plan of vim, and won't change any existing code in vim. We can still happily use vim as usually. 2. If it succeeded, then we would have another powerful free/open source editor in our community. 3. If it failed, then we as a community have nothing to lose. The author might be unhappy then, but he would at least gain lots of experience.

There are so many rewritings happen in this community, and they are definitely good things:

- svn is a rewriting of cvs, and git is a totally new one (with more features?) written from scratch. - nginx was written even if there's apache httpd - There's zookeeper, but people wrote etcd - etc.

Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action.

A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the rewrite, before it has proven itself. When the inevitable happens and schedules slip, defects arise, and features need to be cut this can prove disastrous for a rewrite that you've foolishly committed to in advance. Also, people often ignore the value of years of productive use which provides testing and validation of immense value.

If you have the resources often the best choice is to spin off a new project for a rewrite and have them compete in the open. With luck the rewrite could become mature enough to overtake the original (as has happened with many projects). Alternately, work in phases doing refactoring in steps, perhaps with new features behind feature flags.

Many people think that rewriting code is easier than green field development, in reality it's often more difficult. It takes a great deal of skill, and often luck, to manage a good rewrite.

Sentiment like this is not valuable. The experience that it comes from is often informative, but as a conclusion, this explicitly ignores circumstances that sometimes do make rewriting a good, compelling course of action.

Truly bad, unmaintainable code exists. It exists on projects that have long intended futures. It exists in all sorts of environments on all sorts of projects for all sorts of reasons. To discount the idea of a rewrite out of hand is a failure to objectively review the specific circumstances around whatever it is you're working on.

Often there are better ways, and yes, often a rewrite is a bad idea. But absolutes are so rarely valid, and this one is most certainly not universally true.

Of course you can rewrite from scratch. You just should not expect to reach the same feature coverage instantly, and should approach the work methodically. Most of all, you should have a good reason. "This code is spaghetti" is usually not one. "I want to implement feature X and the current codebase does not really support is" could be a good reason.

Also, a rewrite is pointless from the point of view of code quality unless you are familiar with similar codebases operating in a similar domain.

Main advantages or rewrite are, that when you are a domain expert and implementing and designing core routines, you get constant flashes of intuition "Aha, I should add this interface here because that will enable me to implement Foo and Bar using this instead of writing a FooSubsystem and BarSubsystem" and so on.

If you have no experience from the domain, you get those insights only after you've written the code and are actually new proud owner of new heap of semi-maintainable code.

Rewrites fall into two categories: essential to business and doomed to fail. If it's essential that the business execute on a rewrite, it will happen or the business will fail. If it's not essential, it very well might be the reason the business fails (siphoning away talent and squandering time when a refactor or benign maintenance would suffice). Precisely because massive rewrites are so risky, they are undertaken by the foolish (myself firmly in this camp). The heuristic under which they might succeed is bare necessity.

That first commit also shows it is not a rewrite, though, since it has a comment starting with "Import vim from changeset v5628:c9cad40b4181"

Don't really think so. At least as far Netscape 6 went, they came up with an entirely different framework and moved over to Java (as far as I remember). I have rarely seen that sort of thing characterized as a refactor (even on their mailing lists).

These guys don't have these pressures, nor did (as per haberman's comment) Linux, tmux, Clang, WebKit, etc as far as I'm aware.

So, the engine that Spolsky was saying was a mistake has now been in use for twice as long as the engine it was replacing.

So it's more like taking the old netscape code and making gecko.

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

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.

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.

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