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

151–160 of 239 posts

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

#151

Post by mreiland »

djur wrote: post #137
forgottenpass wrote: post #106

Earlier quoted context omitted.

The 'ol "raising awareness" argument is way too slippery to be nailed down and often leads people to finding exactly the interpretation w/r/t utility that they want. Regardless, I think it's pretty reasonable to suggest that telling a community of developers "old code is a bit shit" isn't useful. Especially when the code in question is on a codebase that already has a serious modernization effort underway. And there…

The author of the blog post[1] associated with that code sample has, in fact, attempted to submit patches to the original vim codebase. Many people have. They were rejected. That's why neovim exists now. So this is providing criticism in the service of providing a solution. [1]: http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

The author is not the one who was being responded to, that's a lazy strawman argument.

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

#152

Post by rootbear »

Artemis2 wrote: post #124
rootbear wrote: post #65

I assume portability is why the function declaration is old K&R style and not ANSI prototype style. I'm always surprised when I see K&R style in modern(ish) code. I do miss the ability to declare multiple parameters of the same type without repeating the type name, though. Oddly, several modern languages (like D) seem to think that's a feature.

> I do miss the ability to declare multiple parameters of the same type without repeating the type name It's a feature Go has!

Yes! I was pleased to see that.

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

#153

Post by PhasmaFelis »

jrbrtsn wrote: post #126
winternewt wrote: post #99

Earlier quoted context omitted.

vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.

Most likely you've typed Ctrl-S, which causes the terminal to pause. Here is the what the vim docs have to say about that: Note: CTRL-S does not work on all terminals and might block further input, use CTRL-Q to get going again.

That is fascinating to me, in a train-wreck sort of way.

We had a discussion a few days ago about the ways in which some interfaces (command line in particular) can be user-hostile. (https://news.ycombinator.com/item?id=9831429) Vim's Ctrl-S appears to be a function, keyboard-adjacent to several commonly-used functions, whose main effect for many users is "cause the program to fail immediately with no indication of how to fix it." I don't think I could make up a better example of user-hostile design if I tried.

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

#154

Post by dang »

tastynacho wrote: post #70
brandonwamboldt wrote: post #49

Earlier quoted context omitted.

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.

You can do whatever you like, but if you were raised right than you'd understand his point. Criticizing something that is broken with no desire/ability/whatever to fix just makes you look like a douche. If you can't do anything about it keep it to yourself; you're just wasting time otherwise.

Personal attacks are not allowed on Hacker News.

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

#155

Post by carterehsmith »

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

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

#156

Post by vacri »

cpncrunch wrote: post #83
Alupis wrote: post #67

Earlier quoted context omitted.

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

I don't know whether it's technically a bug or not, but vim is often a bit slow. For example, 'o' to open a new line in insert mode sometimes takes up to two or three seconds to work. Not a huge problem, but enough to make my mental flow stumble. I have a small vimrc that's mostly tab-related stuff, so I don't think it's that.

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

#157

Post by jcl »

This reminds me of a talk at last year's CppCon about modernizing legacy code. In it, they talked about a core output function of the MSVC standard library that had accreted enough #ifdefs over the years that the function signature alone spanned over 100 lines. It's a great example of how repeatedly making the minimal necessary change can drive code into an unmaintainable mess.

When the team found that the function was impossible to modify to accommodate C99 format string changes, they undertook a lengthy project to factor out the #ifdef'd features using abstractions available in C++. Not only were they able to turn the code into something much easier to modify, but they also fixed multiple hidden performance bottlenecks, so the end result actually ran 5x faster than the C version.

https://youtu.be/LDxAgMe6D18?t=69

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

#158

Post by jhallenworld »

JOE never tries to use poll or select (it uses multiple sub-processes writing to the same pipe to implement input multiplexing). This archaic way works on all version of UNIX, even very old ones which don't have select() or poll(). No #ifdefs needed :-)

Output processing in JOE is interesting: when writing to the terminal, JOE periodically sleeps for a time based on the baud rate and amount of data. This is to prevent too much output buffering so that at low baud rates you can interrupt the screen refresh with type-ahead. If you don't do this at 1200 baud it's a big issue (you could wait for hours if you hit PageDown too many times).

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

#159

Post by 3d8995163 »

ianamartin wrote: post #119
joosters wrote: post #64

Earlier quoted context omitted.

Yeah, on a re-read, my comment is too sure of itself. Never say never! But while there are always edge cases, IMO code rewriting is something that is almost never worth it. Especially a maintainability rewrite just for the sake of maintainability.

I'm so sick of hearing this tripe. Rewriting code is almost always a good idea because after you re-write it, you have some snowball's chance in hell of understanding it. Oh, but Jeff Attwood said . . . Whatever. And then Jeff Atwood said something very different. Blah, blah, blah. If the engineer that wrote the code isn't at the company anymore, and no one really gets it now, rewrite it. At least you will have some…

Are you trolling? This is one of the most wrong things I've ever read on HN. To take the most obvious point - how are you supposed to rewrite the code if you don't understand what it does?

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

#160

Post by 6502nerdface »

PhasmaFelis wrote: post #153
jrbrtsn wrote: post #126

Earlier quoted context omitted.

Most likely you've typed Ctrl-S, which causes the terminal to pause. Here is the what the vim docs have to say about that: Note: CTRL-S does not work on all terminals and might block further input, use CTRL-Q to get going again.

That is fascinating to me, in a train-wreck sort of way. We had a discussion a few days ago about the ways in which some interfaces (command line in particular) can be user-hostile. ( https://news.ycombinator.com/item?id=9831429 ) Vim's Ctrl-S appears to be a function, keyboard-adjacent to several commonly-used functions, whose main effect for many users is "cause the program to fail immediately with no indication of…

It is not "Vim's Ctrl-S"; it's the terminal emulator's ctrl-s. Same thing happens in less, for example.
Post reply on HN