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