Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim's 400 line function to wait for keyboard input

geoff.greer.fm

Post reply on HN
Print view View original

141–150 of 239 posts

Re: Vim's 400 line function to wait for keyboard input

#141

Post by falcolas »

kosma wrote: post #24

There's a deeper underlying problem: the bit of code lacks any architecture. Even though libuv and others didn't exist back then, that's no excuse to just pull random descriptors from various parts of the program and stuff them in a select, repeating variants of the same logic over and over. Even creating a consistent notification/callback interface would make the code much more readable, as the underlying pattern is…

How much would that have cost in speed 10, 20 years ago? Function calls aren't free, and their cost was pretty high before Moore's Law all but erased it.

Re: Vim's 400 line function to wait for keyboard input

#143

Post by userbinator »

breadbox wrote: post #55

There is nothing wrong with supporting lots of platforms, but those #ifdefs need to be encapsulated in wrappers functions (or macros). This is a classic example of premature optimization, actually. You use one or two #ifdefs directly because you hate to pay the cost of function overhead just to make the code easier to read. (Even though there's practically no point in tiny optimizations just before the code is going…

You can easily skip over the #ifdefs - they're all very short.

IMHO I'd rather scroll over code I'm not interested in, than have to jump around to figure out what really happens if they are defined.

Re: Vim's 400 line function to wait for keyboard input

#144

Post by dlubarov »

harmil wrote: post #101
solutionyogi wrote: post #87

Earlier quoted context omitted.

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 soluti…

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 a…

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.

Re: Vim's 400 line function to wait for keyboard input

#146

Post by MereInterest »

jrbrtsn wrote: post #126
winternewt wrote: post #99

Earlier quoted context omitted.

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.

Re: Vim's 400 line function to wait for keyboard input

#147

Post by biggestbob »

harmil wrote: post #101
solutionyogi wrote: post #87

Earlier quoted context omitted.

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 soluti…

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 a…

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

Re: Vim's 400 line function to wait for keyboard input

#148

Post by hkmix »

biggestbob wrote: post #147
harmil wrote: post #101

Earlier quoted context omitted.

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 a…

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.

Re: Vim's 400 line function to wait for keyboard input

#149

Post by hkmix »

nanofortnight wrote: post #109
nothrabannosir wrote: post #105

Earlier quoted context omitted.

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.

Re: Vim's 400 line function to wait for keyboard input

#150

Post by nitrogen »

MereInterest wrote: post #146
jrbrtsn wrote: post #126

Earlier quoted context omitted.

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).
Post reply on HN