Vim's 400 line function to wait for keyboard input • Hacker News Board

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

#101

Post by harmil » Wed, Jul 15, 2015, 8:39 PM UTC

solutionyogi wrote: post #87

Alupis wrote: post #67

Earlier quoted context omitted.

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

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

#102

Post by stuartaxelowen » Wed, Jul 15, 2015, 8:40 PM UTC

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…

Your solution sounds like Enterprise Java to me - instead of understanding one long simple solution, you have to understand 3 shorter, less simple solutions.

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

#103

Post by Watabou » Wed, Jul 15, 2015, 8:45 PM UTC

winternewt wrote: post #99

cpncrunch wrote: post #83

Earlier quoted context omitted.

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.

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.

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.

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

#104

Post by wyldfire » Wed, Jul 15, 2015, 8:47 PM UTC

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…

Or don't use them at all. For where the behavior must be different, create different source files with the same function signature. When building, link only with the implementation appropriate for the target being built.

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

#105

Post by nothrabannosir » Wed, Jul 15, 2015, 8:47 PM UTC

Alupis wrote: post #67

ggreer wrote: post #48

Earlier quoted context omitted.

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed. A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system c…

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

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?

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

#106

Post by forgottenpass » Wed, Jul 15, 2015, 8:51 PM UTC

adrusi wrote: post #98

tastynacho wrote: post #70

Earlier quoted context omitted.

You can do whatever you like, but if you were raised right than you'd understand his point. Criticizing something that is broken with no desire/ability/whatever to fix just makes you look like a douche. If you can't do anything about it keep it to yourself; you're just wasting time otherwise.

Wow that's rude. No need to insult someone's upbringing on a thread based on their musings about a snippet of code. Also you're wrong. Critique is useful in and of itself, not just as a direct means to getting something fixed. If person A doesn't have the time/skill to fix something, they can critique it, hope that person B sees the critique and goes on to fix it. Also, by critiquing it, it starts a discussion about…

The 'ol "raising awareness" argument is way too slippery to be nailed down and often leads people to finding exactly the interpretation w/r/t utility that they want.

Regardless, I think it's pretty reasonable to suggest that telling a community of developers "old code is a bit shit" isn't useful. Especially when the code in question is on a codebase that already has a serious modernization effort underway. And there are already numerous better presented articles online introducing the ways open source could use someone's contribution and calls the reader to action.

Sitting around and "providing criticism" ad nauseam is also a hindrance, disservice, and bikeshed.

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

#107

Post by akkartik » Wed, Jul 15, 2015, 8:54 PM UTC

ggreer wrote: post #48

joosters wrote: post #13

But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed. A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system c…

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

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

#108

Post by sigzero » Wed, Jul 15, 2015, 9:04 PM UTC

solutionyogi wrote: post #87

Alupis wrote: post #67

Earlier quoted context omitted.

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

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

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

#109

Post by nanofortnight » Wed, Jul 15, 2015, 9:04 PM UTC

nothrabannosir wrote: post #105

Alupis wrote: post #67

Earlier quoted context omitted.

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

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/

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

#110

Post by masukomi » Wed, Jul 15, 2015, 9:06 PM UTC

joosters wrote: post #13

But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.

> But the code works.

...is exactly the type of thinking that results is countless of wasted developer time wading through unmaintainable crap, which is never touched because "the code works" and everyone's to damn afraid to change it because it's so excessively complex because no-one bothered to go back and refactor it for readability, maintainability, modern libraries, or anything else.

"working" isn't good enough.