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

171–180 of 239 posts

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

#171

Post by tsuyoshi »

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 is, without question, the worst C codebase I have seen."

From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter.

Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Everyone knows that; it has been pointed out so many times that it's a cliche. But if you look at the source to the implementation, you will find that it was developed by someone who is so incompetent that whether they care or not is beside the point. Dealing with that codebase (and thinking about how successful PHP has become) made me question my will to live.

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

#172

Post by ForHackernews »

carterehsmith wrote: post #155
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.

It is a good goal for sure. That said, how does one go about submitting a "fix" for such a widely deployed software? Like, before submitting, I need to make sure it works on Amiga, VMS, Irix... and then all the current platforms. That is, like, a pretty high barrier... who in the world has all these platforms handy for testing? You submit a patch and someone says that it has a problem on Xenix 2.37.4 -- what do you d…

> who in the world has all these platforms handy for testing?

This was the OpenBSD project's testing rack in 2009: http://www.openbsd.org/images/rack2009.jpg

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

#173

Post by t3f »

tyho wrote: post #120
wspeirs wrote: post #90

Earlier quoted context omitted.

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.

How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.

There are a lot of companies with VMS environments that _must_ be regularly updated/patched/maintained with various security bits for SOX compliance or the like. There certainly are places with static installs that are carefully guarded, but that doesn't mean there isn't a poor admin/dev/user who appreciates an updated or patched version. Heck, he might be the guy doing the porting in his spare time to make his day job better. Often if your seeing regular updates to continue support for an obscure system, its a good bet someone using that environment is the key contributor for their own sanity.

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

#174

Post by jschwartzi »

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…

There is no such guarantee when using CLOCK_REALTIME. If you need this guarantee, use the monotonic clock. I've had issues with graphics engines written naively assuming nobody would change CLOCK_REALTIME. It's a bad assumption because many embedded systems well not use ntp and will instead rely on a user to set the clock. It may go backwards if the user sets it backwards. It may even do so while your software is doing something like presenting the user with a UI to set the time.

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

#175

Post by jheriko »

there is no excuse for this. its trivially refactorable into something easier to maintain with less ifdefs if you are willing to include/exclude files by platform. (and if not, just wrap whole file contents in single ifdefs)

this is a monster that has grown over time without any proper love.

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

#176

Post by jheriko »

joosters wrote: post #60
samf wrote: post #20

Earlier quoted context omitted.

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.

I bet that it contains fewer bugs than a rewrite of the code will have! That code represents years of tweaks, fixes and obscure workarounds. There are countless problems that you will re-introduce with a code rewrite, because the subtleties in aged, thoroughly-used code are not immediately obvious.

the quality of the code shakes my faith in whoever debugged or fixed anything to have not introduced more bugs as they did so.

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

#178

Post by smt88 »

tsuyoshi wrote: post #171
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…

"Vim is, without question, the worst C codebase I have seen." From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter. Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Ev…

The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular.

The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code. I've seen some talks by the PHP maintainers (as recently as 2013) that made me want to throw something at my monitor.

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

#179

Post by jberryman »

UberMouse wrote: post #127
eridius wrote: post #112

Earlier quoted context omitted.

Your blog post recommends using NeoVim today. I've considered looking at it several times, but the home page[1] still says Is it ready to download and run now with all the features? No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change. This warning is why I haven't yet tried switching over. Are they just being overly-cautious?…

I use Neovim as my daily editor, it definitely has it's quirks over Vim (sometimes it takes over 10 seconds to write to certain files, locking up Neovim and there are some bugs with the fuzzy finder I use that cause file corruption that aren't present in Vim) but on the whole it's pretty stable. Haven't encountered any issues yet that are more than a minor annoyance.

File corruption and sketchy saving sounds like a nightmare

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

#180

Post by spydum »

t3f wrote: post #173
tyho wrote: post #120

Earlier quoted context omitted.

How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.

There are a lot of companies with VMS environments that _must_ be regularly updated/patched/maintained with various security bits for SOX compliance or the like. There certainly are places with static installs that are carefully guarded, but that doesn't mean there isn't a poor admin/dev/user who appreciates an updated or patched version. Heck, he might be the guy doing the porting in his spare time to make his day j…

This does raise the question though: when is it appropriate to drop old platform support for any OSS project, and how do you even measure it? User surveys seems insufficient.
Post reply on HN