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

11–20 of 239 posts

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

#11

Post by ProAm »

erikb wrote: post #6

To answer most questions here: Yes, nowadays there are cross-platform libraries you can use instead of implementing that yourself. And yes code that has grown for centuries and contains unnecessary things or patterns that aren't used nowadays can be refactored. Or at least that's how I'd interpret the article.

I really dislike the code review witch hunts you see on HN (or anywhere). On one side of the coin you have startups that merely want to get something thrown together with duct tape, working and ship so they can refactor later and clean things up. On the other hand you have people writing blogs posts to humble brag their code reading and blogging ability.

No one knows the circumstances that created this original code. The developer may have been working on 10 projects and threw something together just so it'd work.

If it ain't broke....

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

#12

Post by chronial »

austinl wrote: post #10
AdmiralAsshat wrote: post #3

To my knowledge, maintaining compatibility is one of the stated goals of Vim, even at the expense of performance. NeoVim is supposed to strip out some of these antiquated features.

Also, it just so happens that the people working on NeoVim are currently porting all IO to libuv (the cross-platform library mentioned in the article). https://github.com/neovim/neovim#whats-being-worked-on-now

See here: https://github.com/neovim/neovim/commit/4528046

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

#13

Post by joosters »

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.

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

#14

Post by DSMan195276 »

geofft wrote: post #5
pkaye wrote: post #2

The question is do you think it could have been done better given that they support multiple OS/UI, etc...

You can refactor it into multiple functions (#ifdefs around a line containing just "||"? seriously??), some of which are no-ops on some platforms / configurations, and let the compiler deal with inlining the functions that exist and optimizing out those that don't. (Not that you would have noticed the overhead anyway, probably.)

I agree with you. Not all of this can be refactored into separate functions, but the parts that can't can be refactored to be much cleaner after you remove the #ifdef's made unneeded by the functions.

Generally speaking, a lot of the cross-platform stuff in the Linux Kernel is handed this way, and done correctly there shouldn't be any over-head.

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

#15

Post by dustingetz »

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 wonder why didn't the vim folks write the abstracting library?

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

#16

Post by DSMan195276 »

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…

A slight nit-pick, though I was going to say the exact same thing - `|| 0`. If you do `|| 1` the compiler's going to optimize the entire 'or' expression out ;)

I was thinking that using `0` would cause a problem when you select none of those compilation options, but then I realize the code won't even compile if you don't select at-least one (You get empty parenthesis fallowing the '&&' in the 'if' statement), so it doesn't seem like a big deal.

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

#17

Post by jsprogrammer »

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.

>There is nothing to be gained.

What about easier extensibility? Not many are going to want to look at that code, let alone try to add some additional functionality to it.

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

#18

Post by chadgeidel »

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

EDIT: Joel isn't actually recommending "do nothing" - on the contrary - the article goes into some depth on ways one can improve software without throwing everything away and starting from scratch.

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

#19

Post by nkassis »

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.

"There is nothing to be gained." Not completely true, you could argue that it would be more maintainable in the future but I don't think that outweigh the risk of making changes here while it's still fully functional and nothing really needs it to change.

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

#20

Post by samf »

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.

How do you know it works? Did you test it on every platform?

What you would have to gain is maintainability. Maybe it's not worth it; maybe it is. But saying that there is nothing to be gained is just an opinion.

Post reply on HN