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

81–90 of 239 posts

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

#81

Post by acqq »

pjmlp wrote: post #30
geofft wrote: post #23

Earlier quoted context omitted.

And your old code doesn't have a test suite you can run on the new code? Well there's your problem. Testless code doesn't acquire bugs by just sitting around on your hard drive, but it doesn't lose any bugs that way, either, and without a test suite you can't afford to do anything but leave it sitting around.

Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as

It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.

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

#82

Post by brudgers »

justin66 wrote: post #28
chadgeidel wrote: post #18

Earlier quoted context omitted.

I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html From the article: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive…

Ken Thompson: "And I've always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I've never been a lover of existing code. Code by itself almost rots and it's gotta be rewritten. Even when nothing has changed, for some reason it rots."

Thompson wrote Vi's predecessor ed. It is purported that he was a user of Rob Pike's sam editor from Plan9.

http://www.catb.org/esr/writings/taoup/html/ch13s02.html

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

#83

Post by cpncrunch »

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.

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.

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

#84

Post by rasz_pl »

Camillo wrote: post #7

I'm a bit surprised that they have code like this: if (msec > 0 && ( # ifdef FEAT_XCLIPBOARD xterm_Shell != (Widget)0 # if defined(USE_XSMP) || defined(FEAT_MZSCHEME) || # endif # endif # ifdef USE_XSMP xsmp_icefd != -1 # ifdef FEAT_MZSCHEME || # endif # endif # ifdef FEAT_MZSCHEME (mzthreads_allowed() && p_mzq > 0) # endif )) When they could have written: if (msec > 0 && ( # ifdef FEAT_XCLIPBOARD xterm_Shell != (Wid…

I looked at the spaghetti in your post and assumed it was a joke .. but then I looked at the real code :(

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

#86

Post by Retric »

pjmlp wrote: post #30
geofft wrote: post #23

Earlier quoted context omitted.

And your old code doesn't have a test suite you can run on the new code? Well there's your problem. Testless code doesn't acquire bugs by just sitting around on your hard drive, but it doesn't lose any bugs that way, either, and without a test suite you can't afford to do anything but leave it sitting around.

Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as

One of my favorite quotes when QA ‘let’ an obvious bug into production was:

“We stopped testing his code five years ago.”

You can take this in many ways, but in the end getting the right amount of testing is a really hard Cost / Benefit problem and there is no one size fit’s all solution.

PS: From the same dev, "I don't trust QA." and "TDD/Code contracts/etc. sounds nice, but knowing what the output should be is really the hard part and tests don't help you with that."

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

#87

Post by solutionyogi »

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.

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

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

#88

Post by kevingadd »

haberman wrote: post #51
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. The "#ifdef maze" in OpenSSL was criticized by the OpenSSH/OpenBSD guys as a key part of the picture that allowed something like Heartbleed to happen: http://blather.michaelwlucas.com/archives/2071 Tons of ifdefs make it much more difficult to ensure that all permutations of flags are correct, or can even compile. I think I remember reading that OpenSSL wasn't even capable of being compiled with…

Every time I deal with ifdef mazes I regret it. MonoGame is a familiar & nasty example, since it tries to be a portable reimplementation of a game framework (with ~a dozen platform targets/backends) but instead ends up being catastrophically buggy - as an end user or a maintainer you can't tell which functions are even implemented or syntactically valid.

I started using a SDL2-only fork of the same library (just one backend! near-0 ifdef count!) and suddenly all those nasty problems went away.

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

#89

Post by Hoff »

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…

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.

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

#90

Post by wspeirs »

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…

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