[Reebles]

Not sure why Bram doesn't believe that removing support for obsolete OSes such as MS-DOS, Amiga, and BeOs helps with Neovim's goal of simplifying the codebase and maintenance. Are there even any actual users of these systems that are disappointed that they won't be able to use neovim? If they're satisfied on those OSes surely they'd be satisfied with legacy vim.

[johncoltrane]

That's not what he said. He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.

[coldtea]

>He said that Neovim's goals could be achieved without cutting out features and removing supports for exotic OSes.

That's the same as what parent said.

Neovim's #1 goal (from the webpage) is: "Neovim is a project that seeks to aggressively refactor Vim in order to simplify maintenance and encourage contributions". And other goals including adding new features for the future.

You might not 100% HAVE to drop "supports for exotic OSes" for that, but is extremely logical, and very much helpful in that direction.

Anything that reduces code size makes it easier for maintanance. You don't want to have to check how things play for those IFDEFS for Amiga OS when you write code for 2014.

[martanne]

In my opinion starting out from the mess that vim's code base has become over the years, can't result in something good.

That is why I started from scratch:

https://github.com/martanne/vis

[Osiris]

The best part of the repository is the README explanation about how it works.

[Argorak]

Given that the statement is very short, I'd expect that cutting out features is the point Brad puts more weight on.

For example, Neovim has plans to remove ex:

https://github.com/neovim/neovim/issues/1089

Exotic is also a matter of definition, there are still applications in use on those oses, and supporting them is a service to those that have to work in them. Not everyone is building apps for Heroku deployment nowadays.

[oblio]

While true, many of those OSes are not updated anymore. So good old Vim (4, 5, 6, 7) will serve them just fine. More than that, several of them (Amiga, BeOS, etc.) run on underpowered machines so the latest and greatest Vim updates won't run on them anyway. We could say that they're well served by Vim 5, for example.

In your concrete example of a feature being removed, Neovim is actually removing a misfeature: the interactive ex mode, not the command line ex mode. The feature they're removing is akin to: http://xkcd.com/1172/.

[kps]

I use ex maybe once a year, when $TERM is screwed up or latency is terrible, but to me removing it is a red flag that says the NeoVim folks don't really grok vi.

[dllthomas]

This was my initial take, but all that's really being removed is the ability to switch between ex mode and visual mode - to which my objection is substantially weaker (to the point that code clarity and separation of concerns are probably more important).

[farresito]

I'm not aware of any vim developer that uses the ex mode, to be honest. Simplicity is a feature, and when something like ex mode is bloating the code, the best option is to remove it. There are other better ways to script neovim.

[dllthomas]

Hi! I am a developer who uses ex mode from time to time. Now you're aware of one.

I objected when I thought they were removing all support for ex; as it turns out, they're only removing support for switching between visual mode and ex mode - making them two separate front-ends. That's not a problem.

[exDM69]

This has been discussed before and several people said they use ex for scripting (with pipes). However, NeoVim is not removing that, only the UI for ex mode.

[riffraff]

I guess Bram's point of view is that you could refactor the codebase without removing support, i.e. instead of a 400 line function with ten ifdefs, a 20 line one for the "sane" platforms and extra per-platform shims overriding it.

I am with the neovim guys on this, but you can refactor without removing features (in fact, the original meaning of "refactoring" was in fact "code improvements with no functionality changes")

[wojt_eu]

Dropping support for exotic OSes frees you from having to test on that OSes.

[johncoltrane]

A refactoring that removes features is not a refactoring; it's a massacre.

And yes, removing features and support for some OSes is not a prerequisite for reaching neovim's goals. It will make it easier for them, that's for sure, but that is absolutely not a given, at all.

[coldtea]

>A refactoring that removes features is not a refactoring; it's a massacre.

Features that aren't used (or used in very rare cases) can, and in many cases should, be ruthlessly cut out in a refactoring.

By definition we care for the features that we care about. If noone (as in: very small value of "some people") cares about Amiga OS support, it should be removed to have a cleaner codebase.

Else in 2050 they'll be wondering what this Oric Atmos is, and why it needs 400 IFDEFS in vim code.

>And yes, removing features and support for some OSes is not a prerequisite for reaching neovim's goals. It will make it easier for them, that's for sure, but that is absolutely not a given, at all.

More mevelopers should get familiar with the notion of "opportunity cost".

[dllthomas]

Removing features that aren't used should often be done, but I'm hesitant to call it "refactoring". Most definitions say that a refactor doesn't change external behavior. Removing features has additional ramifications - good and bad - and probably deserves to be called out more explicitly.

[coldtea]

Refactoring in its pure form yes, but people use refactoring to mean any large scale restructuring of a program not just following refactoring patterns that produce the same result as before.

In practice large scale refactoring and change in behavior (dropping some features, fixing some stuff) are pretty much tied together.

[irremediable]

In practice, is it a feature to be available on a given legacy platform? For most users, no relevant feature is lost when legacy support is removed.

[SamReidHughes]

Are you familiar with Vim's code? How is support for those OSes making things substantially more complicated?

[ggreer]

Are you familiar with Vim's code? Just look at all the OS-specific files in the source tree[1]. Not only that, there are ifdefs-galore in the shared code. RealWaitForChar is over 400 lines and contains 41 ifdefs.[2] Many are for long-dead features or platforms. That function just waits for user input, but it has to be ridiculously complicated to account for platforms without basic functions like select(). The infamous eval.c starts off with ifdefs for Amiga, VMS, and Mac OS Classic.[3] Neovim has ripped out tons of this stuff, and it's drastically reduced line count.

1. https://github.com/b4winckler/macvim/tree/master/src

2. https://github.com/b4winckler/macvim/blob/master/src/os_unix...

3. https://github.com/b4winckler/macvim/blob/master/src/eval.c

[dllthomas]

I think the parent can be read as an honest request for more details. It doesn't need to be met with snark.

(Don't take this too harshly - the content in your post is good.)

[SamReidHughes]

How does this stuff get in the way of the features that NeoVim intends to add? -- features they list such as "job control", a msgpack remote API, or a new plugin architecture. (I don't really expect you to be capable of answering this question unless you're familiar enough with the code to give an operational description of how these ifdefs get in the way.)

[coldtea]

You don't have to be familiar with Vim's code to know that having support for obsolete OSes makes the code substantially more complicated.

[dllthomas]

It depends on how much the compatibility issues have been factored out into external libraries. In the case of vim, I think the answer is "substantially not".

[teacup50]

Bulk churn is the kind of easy task that gives the impression of progress while providing very little actual value.

In 8 months, here's what NeoVim has done:

1) Reformatted all the code.

2) Deleted a lot of working, old code.

3) Raised a good chunk of cash.

4) Published a very shiny website.

5) Released nothing.

There's nothing wrong with simplifying a code base, but if you run around trying to do that independent of any reasonable technical direction, you're just making noise.

Given that NeoVim's technical direction is extremely poorly considered (while also disparaging Bram's work), I can't help but think highly of Bram for being polite -- at all -- to such a disrespectful fork.

[ggreer]

Your comment seems to consist of some things that aren't true, and some true things accompanied with baseless insinuations.

1. The code was reformatted because Vim's codebase is a mess. It mixes tabs and spaces willy-nilly. It uses different indentation rules in different parts of files. These issues may seem cosmetic, but they make the code harder to follow and increase the likelihood of bugs. Indentation can be especially misleading when control flow lacks braces (a common occurrence in Vim). The change didn't require much effort and it made it easier for people to contribute to Neovim.

2. Actually, quite a bit of Vim's old platform-specific code is broken. It's just that nobody uses an SGI IRIS or Amiga, so nobody complains about it. In some cases, Neovim removed ifdef'd code that could never possibly be included[1].

3. People have donated less than $40k to Neovim. That's not even the salary of a single developer for the 8 months it's been around. The contributors aren't in it for the money. They simply want to build a great editor.

4. A very shiny website? It's just static pages hosted on Github. If you look at the commit history[2], you can see it's insignificant compared to work done on the Neovim codebase.

5. Nothing? There's an entire repository of working code. Right now you can clone Neovim, compile it, and it will run almost all Vim plugins without issue. The team is very conservative about declaring software stable. They may not have a tagged release, but to call the existing work "nothing" is unreasonable. It's at least as stable as Atom.

You also neglected to mention all the other work done on Neovim, such as replacing ad-hoc cross-platform compatibility and event handling with libuv. Then there's the improved plugin APIs which allow features that aren't possible in Vim.[3] And of course, plugins can be written in any language. No more VimL shims needed.

Lastly: Disparaging? Disrespectful? It's hard to find any criticism the Neovim contributors have made towards Bram or Vim. They like Bram. They like Vim. Thiago tried to contribute to Vim multiple times, but was discouraged or ignored.[4][5] Instead of complaining or giving up, he and the other contributors are trying to improve the editor and the community around it. There's no malice or greed involved.

1. https://github.com/neovim/neovim/pull/814

2. https://github.com/neovim/neovim.github.io/

3. https://github.com/benekastah/neomake

4. https://groups.google.com/d/msg/vim_dev/QF7Bzh1YABU/02-YGr7_...

5. https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...

[keithpeter]

"Right now you can clone Neovim, compile it, and it will run almost all Vim plugins without issue."

Easy compile? (I'm at work and no git clone/compiling here!) Might try later on tonight.

[aaren]

Pretty easy (`make install`). You need Cmake with ssl and a not-too-old gcc (>4.3). This should be the case on a modern system.

I recently compiled it on CentOS 5 and had to build my own cmake.

https://github.com/neovim/neovim/wiki/Installing

https://github.com/neovim/neovim/wiki/Building-Neovim

[keithpeter]

Yup, just used the Ubuntu instructions on Trisquel.

[johncoltrane]

Thiago sent two unfinished, non-guidelines-compliant, non-cross-platform and non-working patches to the mailing list. That's his entire history of contributing to Vim.

Neovim is an emo-fork created by a frustrated little princess. Nothing more, nothing less.

There's a lot of work to do on Vim itself; forking it and building a completely incompatible code base is not going to help in any way.

[kev6168]

How is forking an open source project disrespectful? For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input. They have been keeping their heads down quietly working on extremely hard problems.

Natively supporting Lua/LuaJIT and Python in writing asynchronous plugins, this alone is worth the wait. I am willing to give them A LOT MORE than 8 months if they can pull just this single feature off.

The request for Python integration has been sitting at the top of Vim's voting list for many years. It must be a very very difficult task, otherwise it could be done years ago. http://www.vim.org/sponsor/vote_results.php/

Other than the new plugin infrastructure, Neovim's GUI and embedding systems will be awesome. Anyway, I applaud people who explore and try to make progress (like from Vi to Vim, a natural process). In the mean time, I am happily using Vim which is both extremely powerful and stable.

TL,DR; I can wait.

[btipling]

> For the past eight months I have only seen Neovim folks being very professional, open, and quick to respond to user input.

They've done even more than that. They have gone to great lengths to be helpful. For example, tarruda created an issue on our own issue tracker to let us know they updated their python plugin architecture so that we could fix our Neovim plugin. He didn't have to do this.

https://github.com/Floobits/floobits-neovim/issues/10

tarruda has shown himself to be a very productive engineer and a great steward of a growing Neovim community.

Our experience with Neovim and Vim has been night and day. The reality is that with Neovim you can build plugins that do more than you can with vim, painlessly. I don't really want it to be a vim versus neovim thing, but Bram strikes me as someone who at the very least doesn't understand Neovim's goals. I certainly hope that Neovim's changes are not backported into vim, Neovim is much more open about contributions whereas with vim there's a single gatekeeper with limited time to address big changes.

[PieSquared]

As someone who has worked Neovim and written Neovim plugins, can you comment on how ready it is for "production" use? Could I switch over to it from Vim now, while using all my old Vimscript plugins? Could I right now use it and write plugins that do work on a separate thread from Vim? Is the msgpack API ready and/or documented? etc.

[justinmk]

Before we get another rage post[1] I would like to emphasize that using Neovim requires that you keep up with the changes.

I use it full-time on supported platforms (everything except Windows), but breaking changes will require occasional reconfiguration, recompilation, or remorse.

[1] http://www.reddit.com/r/neovim/comments/2mo54n

[coldtea]

>In 8 months, here's what NeoVim has done: 1) Reformatted all the code.

Even if they had done JUST that and the deprecation of old code, it would be MORE than enough.

[jballanc]

> 5) Released nothing.

I've been tracking the neovim repo for a while, and my feeling is that they could have easily made a couple of releases with stability matching some other notable projects, but they have intentionally chosen to be conservative and wait.

If you want an example of one area where there has been work and improvement, check out the Wiki page on the updated clipboard integration: https://github.com/neovim/neovim/wiki/Python-plugins,-clipbo... . Yeah, it's different, and not yet as capable as Vim's built-in clipboard integration. But if they are headed toward a goal of more generalized integration points, then this is a strong step in the right direction.

[sondr3]

I don't really see any problems here, they haven't made any promises either to release anything either before they are up to speed with where they want to be, just looking at their Github repo shows that there's a lot of activity going on. I'm really looking forward to seeing where they are going. In eight months things may have changed drastically, who knows, but I think that NeoVIM is going to be great. Besides, this is a bit like complaining about vim being a fork of vi, it's how things goes with open source software.

[hjek]

original vi was not free software. vim is a clone, not a fork.

[sondr3]

In that case I stand corrected on that point, however I still feel like it's a bit of the same thing. :)

[dennyabraham]

neovim is in the process of several major under-the-hood refactorings to enable larger scale changes. If it's not immediately apparent to you what the team is working on, you can see the project goals and progress thereupon on the project tracker.

https://waffle.io/neovim/neovim

[sbilstein]

I often refer to these two pieces when debating rebooting a project from scratch:

Joel Spolksy Things You Should Never Do Part 1 http://www.joelonsoftware.com/articles/fog0000000069.html

Darmesh Shah How To Survive a Ground-Up Rewrite Without Losing Your Sanity (a response to essay #1 13 years later) http://onstartups.com/tabid/3339/bid/97052/How-To-Survive-a-...

It's not always cut and dry when you should start over, but if you are make sure you are doing it in a way that starts presenting customer/user value ASAP.