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

181–190 of 239 posts

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

#181

Post by akurilin »

eridius wrote: post #112
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…

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

Been using it daily for several months now, haven't had much trouble with it. Worked seamlessly with over half a decade of accumulated vim plugins and config modifications.

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

#182

Post by kccqzy »

kedean wrote: post #58
jandrese wrote: post #8

This is a classic case of why legacy code is a nightmare to maintain. It's the OpenSSL situation all over again, and one can definitely see the appeal of going through there and ripping out all of the functionality that nobody uses anymore just to make maintenance less of a nightmare. Luckily vim doesn't run suid root on any sane system, so all of this legacy cruft is not as huge of a threat surface on the machine.

It is still an issue, since vi/vim gets used for sudo purposes all the time. Any time someone uses visudo to modify their sudoers file, for example, that's giving root privileges to vim.

Visudo specifically avoids this problem by creating a copy of the sudoers file, invoke the editor as a normal user, wait for it to exit, check syntax and then rename the temporary file into the actual sudoers file.

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

#183

Post by uxcn »

eridius wrote: post #112
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…

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've been trying it for roughly the last month. I have run into a few quirks, for example it uses non-blocking i/o for things with libuv (for stdin), which can interfere with parent processes that expect blocking i/o. If you file a bug report, the issue usually gets fixed quickly.

I've kept vim installed as a fallback so I can easily use vim if I run into anything that is a show-stopper, at least until it's fixed in nvim. I still plan on submitting patches to both for the foreseeable future though.

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

#184

Post by belden »

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.

When I change jobs, I check which version of my editor the dev environments have installed. If it's too old, I build a local copy of the latest version of my editor. No worries asking IT or Ops to update a package for me.

When it comes to production servers, I'm more likely to build my editor in my home directory than use my sudo privileges to install my editor in the system.

So developers can be building newest versions of code on old systems. I do.

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

#185

Post by Watabou »

mintplant wrote: post #121
Watabou wrote: post #103

Earlier quoted context omitted.

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.

vim may still be partly to blame in that case, as it lacks support for async plugins.

Do you also blame Microsoft Word because it doesn't let you play movies?

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

#186

Post by EGreg »

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

Should have unit tested that comment

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

#187

Post by steve_b »

smt88 wrote: post #178
tsuyoshi wrote: post #171

Earlier quoted context omitted.

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

do you have any links to these talks? thanks!

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

#188

Post by roghummal »

sigzero wrote: post #108
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…

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

Another #ifdef would fix that!

A wrapper function could hide the extra #ifdef, taking it out of OP's count. A macro defined during compilation would be even better|harder to understand.

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

#189

Post by roghummal »

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…

If you're going to use 'this is a companion piece to...' as a defense you should link to the original article in the 'companion piece' before you have to use it as a defense.

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

#190

Post by [deleted] »

akkartik wrote: post #107
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…

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

[deleted]
Post reply on HN