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

71–80 of 239 posts

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

#71

Post by brudgers »

stinos wrote: post #42
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…

It doesn't acquire bugs just by sitting around on your hard drive. Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require…

There are also latent bugs which are inconceivable at design time and only become possible after several cycles of Moore's law.

http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

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

#72

Post by jayvanguard »

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.

Your definition of "works" doesn't include "ability to easily absorb change as the world modernizes". The world of computing is changing each year and any software that works well needs to adapt (or else be trivially small like many unix utils so the world adapts around them or abandons them).

I love vim and have looked at contributing a number of times but the sheer amount of cruft creates a huge barrier.

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

#74

Post by raarts »

brandonwamboldt wrote: post #49
cat_dev_null wrote: post #38

If you are all such experts, why don't you "fix it" and then pull request it in.

Please, you can critique something even if you lack the skills to fix it, or the desire to fix it, or the time to fix it. Also, you can point out that something is broken even if you have no suggestions on how to fix it.

bachelors' wives and maidens' children are well taught

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

#75

Post by rando3826 »

stinos wrote: post #42
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…

It doesn't acquire bugs just by sitting around on your hard drive. Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require…

aka bitrot

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

#76

Post by jayvanguard »

chadgeidel wrote: post #18
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 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…

> It doesn't acquire bugs just by sitting around on your hard drive.

Wrong. There are entire classes of bugs that have to do with adapting to new environments, security standards, etc.

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

#77

Post by saosebastiao »

I would much prefer the coeffect system for managing different platforms and capabilities:

http://tomasp.net/blog/2014/why-coeffects-matter/

It would be so amazing to be able to take all of those ifdefs and turn them into type variants and have the compiler enforce the safety and semantics of the system. And it would be phenomenal for old code to break at compile time when the environment changes, instead of waiting for a bug report to roll in.

So, paging T. Petricek...when are we gonna get it in F#? :) Even better if someone can get it into Rust! That is the perfect type of feature for a systems programming language.

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

#78

Post by VLM »

amelius wrote: post #31
dustingetz wrote: post #15

Earlier quoted context omitted.

I wonder why didn't the vim folks write the abstracting library?

Simple. Just imagine how this code evolved. First, they started with a simple 1-liner, that took at most 5 minutes to come up with. Then another platform was added, this took another 5 minutes, etc. Abstracting, however, would take perhaps a day of work. A full library such as libuv would have taken maybe a couple of weeks to develop. So there you are. QED.

If they added libvu support, we'd have a post about "VIM's 430 line keyboard input routine" instead of a mere 400. At least for a major release or so before they could flush the legacy code. If they can.

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

#80

Post by baby »

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.

Depends on what machine you are using Vim from
Post reply on HN