I too have followed the vim mailing list for many years, and tried and failed to submit a patch to it. I mostly use neovim now, and have successfully submitted a patch to it. Based on these experiences I found your blog post unnecessarily incendiary. The thread of your patch submission (https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj...) was actually quite civil. It didn't do what you want, but let's be precise with language here.

To state some blatantly obvious facts, people do open source on their own time, they have limited such time and many commitments, and they explicitly allow forks like neovim for the aspects they can't find time for. Vim and neovim have chosen very different design constraints, and there's no reason why they can't continue to exchange code where it makes sense. Putting one of the two down seems unproductive.

The leaders of large projects like Neovim are seldom critical of the competition, and when they express criticism it is measured and proportionate. We should all learn from them.

(Your OP here is still quite useful. Thanks for putting it together.)

"...they explicitly allow forks like neovim for the aspects they can't find time for."

With the risk of sounding like captain obvious here, but in open source you do not have the luxury to allow or disallow forks, they just happen.

You can use shady licenses to prevent people from re-using your code, or you could not be open source. It is a kinda-explicit green flag.

Someday 'vi' might symlink to 'nvim' instead of 'vim'. 'VI Improved Improved'!

Mr. Greer's post was necessarily incendiary; He's building his brand. Wasting space on the front page of HN is a feather in his cap.

I'm sorry if you thought the post was self-serving. I can only say with sincerity that it wasn't. I have no motive beyond my interest in software.

If you don't believe my claim of selflessness, believe my claim of competence: If I was trying to build a personal brand, I could do much better than delving into Vim's codebase for a one-off snippet. It's not difficult to create insubstantial content that is widely-shared. I can think of a dozen topics whose mere mention can drive immense traffic and waste absurd amounts of time. HN's front page attests to this.

It's a shame that many people scrutinize others for selfishness. Purely selfish behavior is an extreme rarity, yet it takes much longer to refute such accusations than to make them. I wish it were otherwise.

Before deriding others, please remember: Almost no one is evil. Almost everything is broken.[1]

1. A quote from http://blog.jaibot.com/

If you're ever in the Silicon Valley we should "meet up". I'll be nicer to you but you're buying.

>>I don’t consider myself very devoted to my work, but

>Don't try and pretend your problems are our problems. Struggling to survive, scrap by scrap. Fuck off. If you're ever in the Silicon Valley we should "meet up". I'll be nicer to you.

You trawled through my writings to find one sentence in one blog post[1] to voice outrage at. I'm not sure how to react to that. I guess... congratulations on your hard work.

I live in the bay area, but I prefer not to hang out with people who treat others so callously. I hope you understand.

Edit: It appears roghummal has significantly revised his comment since I finished my reply.

1. http://geoff.greer.fm/2015/01/07/burnout-is-in-the-mind/

>Edit: It appears roghummal has significantly revised his comment since I finished my reply.

It doesn't 'appear' that way, that's the way it is. My edit was, just guesstimating here, 25 minutes before your post? Edit was 2-5 minutes after my original post?

You've never said anything you quickly realized was indefensible?

Wrong, even?

So I don't confuse you with an edit and for my own gratification, I'd like you to know that I didn't 'trawl' through your posts to find something that supported mine.

Your titles are bait. Their substance is minimal. When you've had something to say it has been said before, better. If you care about the code as much as you claim you should let it go. (I'm questioning this last statement.)

You're a natural born CEO. Find your Woz.

Edit: And then someone to run your company. (I just saw "Judging from this comment and others, you seem uninterested in civility or truth. I doubt anything can change your mind on this issue.")

You delved[1] into the vim source and found this. You offered no solution except to use neovim, which happens to be 'supported' by the /amazing/ company you're the CEO of. You're very well practiced in false modesty and apologies but fuck you; I'm not sure you know what sincerity means.

I'm sorry if I don't think you're being sincere. Let's have a drink sometime! Let's network!

1. Anything as old as vim, continuously developed, will have any number of these frankenfunctions. They're not hard to find.

Judging from this comment and others, you seem uninterested in civility or truth. I doubt anything can change your mind on this issue.

Still, others read these comments, so I feel compelled to offer corrections: 18 months ago, I pledged $50 to Neovim's Bountysource. My company has not contributed a cent to Neovim. We maintain plugins for many text editors, including Vim and Neovim. That's it.

You keep slinging mud, but there is no ulterior motive at work here. I urge you to treat people more charitably in the future.

Civility works best with mutual respect. That respect might be hollow or fleeting but it's established and traded on. When two people meet for the first time there's a credit exchanged. That's the humanity-freebie.

Don't ask for sympathy ("They don't want civility or truth!!!"), ask yourself why you were treated "uncivilized".

Truth? I suspect that's a glitch in translation.

I'm really sad neovim didn't call themselves vi improved improved, or vii. It doesn't just carry the naming tradition of vim, but is also one more than vi.

If it had we might be running it right now.

"Vim is, without question, the worst C codebase I have seen."

From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter.

Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Everyone knows that; it has been pointed out so many times that it's a cliche. But if you look at the source to the implementation, you will find that it was developed by someone who is so incompetent that whether they care or not is beside the point. Dealing with that codebase (and thinking about how successful PHP has become) made me question my will to live.

The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular.

The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code. I've seen some talks by the PHP maintainers (as recently as 2013) that made me want to throw something at my monitor.

llvm and redis have good reputations. sqlite, I think. Lua. llvm in particular seems to owe its popularity to good structure, though it does seem to be an exception that highlights the common case.

Checkout the Nginx source. It's pretty damn good.

do you have any links to these talks? thanks!

I can't find the one I was thinking of, and I don't want to comb through literally hours of video to figure it out. This should illustrate my point, though:

https://en.wikiquote.org/wiki/Rasmus_Lerdorf

And also here where he makes a breaking commit without running unit tests first:

http://www.reddit.com/r/programming/comments/jsudd/you_see_r...

Need an excuse to buy a new monitor by any chance? :)

Your blog post recommends using NeoVim today. I've considered looking at it several times, but the home page[1] still says

Is it ready to download and run now with all the features?

No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change.

This warning is why I haven't yet tried switching over. Are they just being overly-cautious?

[1]: http://neovim.io

I use Neovim as my daily editor, it definitely has it's quirks over Vim (sometimes it takes over 10 seconds to write to certain files, locking up Neovim and there are some bugs with the fuzzy finder I use that cause file corruption that aren't present in Vim) but on the whole it's pretty stable. Haven't encountered any issues yet that are more than a minor annoyance.

> ...there are some bugs with the fuzzy finder I use that cause file corruption...

Having your text editor corrupt the file it's working on sounds like the absolute worst case scenario.

Is this fuzzy finder thing some third-party plugin? Do you have any idea why it corrupts the files that you point it at?

It's a third party plugin, it's definitely a Neovim issue because the file corruption doesn't happen with Vim. No idea why it happens. I'm fine living with it because I just check the file back out if it corrupts it. It's only an issue when opening a new file so it doesn't cause work to be lost.

A github issue about it https://github.com/junegunn/fzf/issues/206

File corruption and sketchy saving sounds like a nightmare

I've been trying it for roughly the last month. I have run into a few quirks, for example it uses non-blocking i/o for things with libuv (for stdin), which can interfere with parent processes that expect blocking i/o. If you file a bug report, the issue usually gets fixed quickly.

I've kept vim installed as a fallback so I can easily use vim if I run into anything that is a show-stopper, at least until it's fixed in nvim. I still plan on submitting patches to both for the foreseeable future though.

I use it daily and it's been fine.

I use it with true color support enabled, and a terminal that supports true color, and a patched version of tmux that supports true color, and finally all color schemes render as they do in gvim!

Also the terminal emulator feature is awesome.

yeah, there is a good chance you'll not run into problems. however new, serious bug reports come in frequently. for example a lot of people have been seeing segfaults, and nobody seems to know where to look. Although Neovim's codebase is significantly cleaner than vim's, its still a far cry from what I would call good.

Been using it daily for several months now, haven't had much trouble with it. Worked seamlessly with over half a decade of accumulated vim plugins and config modifications.

Try kakoune[0]. As far as I can see, it's stable today. Just try not to think about how the name sounds shitty.

[0] https://github.com/mawww/kakoune/

But that's not Vim-compatible. I have a ton of Vim plugins that I rely on. Switching to a brand new editor is rather untenable.

> The code works, but it's quite buggy

Could you elaborate a bit? I've never experienced a bug related to keyboard input while using Vim, at least that I know of.

He covers in the blog post: http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

From the blog post:

That if statement’s conditions span 17 lines and 4 different #ifdefs. All to call gettimeofday(). Amusingly, even the body of that statement has a bug: times returned by gettimeofday() are not guaranteed to increase. User intervention or ntpd can cause the system clock to go back in time. The correct solution is to use a monotonically increasing time function, such Linux’s clock_gettime() or OS X’s mach_absolute_time().

ntpd guarantees (under the default settings now, though that's new... you can ask it to shoot you in the head, but I don't recommend that you use firearms in this way) that the clock will never go backwards. You're thinking of nptdate, a utility provided with ntpd, but which is only ever supposed to run at system initialization time to get the time close enough for ntpd to take over.

If ntpd finds that the clock is ahead, it will slow the ticks, allowing it to gradually drift back to the correct time.

The system time should NEVER move backwards. Ever. Relying on the system time not moving backwards is not unreasonable for trivialities like how long you wait for a keystroke. If you reset your system time, you might have to hit a key to get vim to wake up. Shucks.

ntpd will step backward if error stays above a configurable threshold for a configurable period of time. We saw it happen after the recent leap second. 1 second exceeds the default step threshold of 128 ms. With Linux limiting the slew rate to 500 ppm, gradual correction would have taken 2000 seconds, and by default nptd steps after 900 seconds.

> ntpd guarantees (under the default settings now [...]) that the clock will never go backwards.

Can you elaborate on what changed? I just downloaded the latest reference implementation, and the man page still seems to indicate that the default behavior is to step when error > 128ms for a prolonged period.

There is no such guarantee when using CLOCK_REALTIME. If you need this guarantee, use the monotonic clock. I've had issues with graphics engines written naively assuming nobody would change CLOCK_REALTIME. It's a bad assumption because many embedded systems well not use ntp and will instead rely on a user to set the clock. It may go backwards if the user sets it backwards. It may even do so while your software is doing something like presenting the user with a UI to set the time.

With Linux/NTP there was two times 23:59:59 UTC not long ago: https://access.redhat.com/articles/15145

The clocks go back an hour every year here in (most of) Australia. Every year, on a specific date 1am-2am happens twice.

Do you mean daylight saving time? The time zone changes, but Unix time is UTC so it's unaffected.

> he correct solution is to use a monotonically increasing time function, such Linux’s clock_gettime() or OS X’s mach_absolute_time().

At the expense of supporting FEWER platforms.

Another #ifdef would fix that!

A wrapper function could hide the extra #ifdef, taking it out of OP's count. A macro defined during compilation would be even better|harder to understand.

Me neither. I've been using vim for about 20 years and I don't think I've ever spotted a single bug in that time.

I don't know whether it's technically a bug or not, but vim is often a bit slow. For example, 'o' to open a new line in insert mode sometimes takes up to two or three seconds to work. Not a huge problem, but enough to make my mental flow stumble. I have a small vimrc that's mostly tab-related stuff, so I don't think it's that.

I've also noticed delays when using 'o'. I've always wondered if it might be related to syntax highlighting.

vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.

Most likely you've typed Ctrl-S, which causes the terminal to pause. Here is the what the vim docs have to say about that:

Note: CTRL-S does not work on all terminals and might block further input, use CTRL-Q to get going again.

If you run "stty -ixon", it will prevent Ctrl-S from pausing the terminal. I understand that feature in the days of slow connections, but it feels rather silly at this point.

I use it to pause output from a running batch job (e.g. deployment).

This was my biggest hurdle to learning vim, I kept hitting Ctrl-S...

This might help:

http://vim.wikia.com/wiki/Map_Ctrl-S_to_save_current_or_new_...

(Caveat emptor, can't speak from first hand experience.)

That is fascinating to me, in a train-wreck sort of way.

We had a discussion a few days ago about the ways in which some interfaces (command line in particular) can be user-hostile. (https://news.ycombinator.com/item?id=9831429) Vim's Ctrl-S appears to be a function, keyboard-adjacent to several commonly-used functions, whose main effect for many users is "cause the program to fail immediately with no indication of how to fix it." I don't think I could make up a better example of user-hostile design if I tried.

It is not "Vim's Ctrl-S"; it's the terminal emulator's ctrl-s. Same thing happens in less, for example.

Ah, my mistake. Same criticism applies, though; possibly more so, as a terminal emulator running within a GUI would find it even easier to display a useful status message or similar.

I've never heard of Ctrl-S causing a crash, though. So your explanation at most accounts for the hangs.

I've used vim pretty much every work day in the last 15 years or so, and I can count the number of times it's crashed on one hand. If you can actually verify that it crashed (i.e. core dump file), then you've got the source available, and you can send in the patch.

It's never crashed on me. I'm not the person who claimed it crashed.

Are you sure the crashes aren't caused by a plugin you installed?

I have only experienced a handful of vim crashes but all of them were caused by plugins.

vim may still be partly to blame in that case, as it lacks support for async plugins.

Do you also blame Microsoft Word because it doesn't let you play movies?

People have tried to add async plugin support to vim, but the patches have all been rejected. Meanwhile, the plugin support in Neovim is worlds better.

Microsoft Word doesn't even accept patches, which I do indeed hold against it.

The patches were rejected because they didn't provide a working solution for cross platform support. The plugin system in Neovim is only "better" for people who actually want async plugins. I am not one of them.

When I press ESC, it takes a while to register, and for the UI (e.g. the little "command in progress" buffer bottom right) to reflect this. CTRL+C doesn't suffer this problem, and is almost functionally interchangeable, so I've retrained myself to use that, now.

This is a bug, if you ask me. Or is that impossible for vim to fix?

This is not a bug in vim. This is because Esc was historically used as a Meta key in lieu of the modern use of Alt.

For example, if you use tmux, add the following to .tmux.conf:

    set -s escape-time 0

Other terminal multiplexors and emulators have different commands for this.

Edit: There are a few other possible issues you are having: http://www.johnhawthorn.com/2012/09/vi-escape-delays/

In vim, set separate timeout and ttimeout values to get around this. Specifically, set the former high fit regular commands and the latter low to avoid issues like slow Esc processing.

Depends on what machine you are using Vim from

vim works fine on OpenVMS, as it's in use in some other OpenVMS windows right now. (But thanks for the reminder to upgrade to the most current — upgrades underway.)

I'm not particularly inclined to port neovim to OpenVMS right now, as there are a few other projects in the queue ahead of that.

Many companies (FactSet for example) still use VMS, and vim on those systems... I think folks would be surprised how many legacy systems are still out there.

How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.

There are a lot of companies with VMS environments that _must_ be regularly updated/patched/maintained with various security bits for SOX compliance or the like. There certainly are places with static installs that are carefully guarded, but that doesn't mean there isn't a poor admin/dev/user who appreciates an updated or patched version. Heck, he might be the guy doing the porting in his spare time to make his day job better. Often if your seeing regular updates to continue support for an obscure system, its a good bet someone using that environment is the key contributor for their own sanity.

This does raise the question though: when is it appropriate to drop old platform support for any OSS project, and how do you even measure it? User surveys seems insufficient.

When I change jobs, I check which version of my editor the dev environments have installed. If it's too old, I build a local copy of the latest version of my editor. No worries asking IT or Ops to update a package for me.

When it comes to production servers, I'm more likely to build my editor in my home directory than use my sudo privileges to install my editor in the system.

So developers can be building newest versions of code on old systems. I do.

Lots of people know and contribute to vim. If they try to make life easier for you, they will probably make life worse for all those who are already familiar with vim code. It is similar to the situation of the Linux kernel, where some people would prefer to use C++, while everyone who already works on Linux also knows and prefers straight C. Given the vitality of vim, I think you should just learn it and stop trying to change what already works.

Right. So you recommend neovim, which is good, except that it won't install -- not on some unused OS, but on OS X 10.6.8 (Snow Leopard). Now I know that's a little behind, but really? Beautiful code that won't work on a 2010 OS is just awesome.

As an aside, I think it's a growing problem that the formulae in Homebrew are not updated to support 10.6.8.

And Vim? It just works. Maybe it's all those #ifdefs that make the code look ugly...

Do Apple supply security updates for Snow Leopard still?

Apple doesn't even supply security updates for 10.9 anymore.

So the OS is EOL. In that case why should 3rd party software go out its way to support it?

If you're going to use 'this is a companion piece to...' as a defense you should link to the original article in the 'companion piece' before you have to use it as a defense.