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

201–210 of 239 posts

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

#201

Post by anon4 »

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

Try kakoune[0]. As far as I can see, it's stable today. Just try not to think about how the name sounds shitty.

[0] https://github.com/mawww/kakoune/

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

#202

Post by simoncion »

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.

> ...there are some bugs with the fuzzy finder I use that cause file corruption...

Having your text editor corrupt the file it's working on sounds like the absolute worst case scenario.

Is this fuzzy finder thing some third-party plugin? Do you have any idea why it corrupts the files that you point it at?

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

#204

Post by simoncion »

vacri wrote: post #156
cpncrunch wrote: post #83

Earlier quoted context omitted.

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.

I've also noticed delays when using 'o'. I've always wondered if it might be related to syntax highlighting.

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

#205

Post by mintplant »

Watabou wrote: post #185
mintplant wrote: post #121

Earlier quoted context omitted.

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?

People have tried to add async plugin support to vim, but the patches have all been rejected. Meanwhile, the plugin support in Neovim is worlds better.

Microsoft Word doesn't even accept patches, which I do indeed hold against it.

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

#206

Post by smt88 »

steve_b wrote: post #187
smt88 wrote: post #178

Earlier quoted context omitted.

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!

I can't find the one I was thinking of, and I don't want to comb through literally hours of video to figure it out. This should illustrate my point, though:

https://en.wikiquote.org/wiki/Rasmus_Lerdorf

And also here where he makes a breaking commit without running unit tests first:

http://www.reddit.com/r/programming/comments/jsudd/you_see_r...

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

#207

Post by michaelmcmillan »

riquito wrote: post #97

I've just realized that Vim never exited with an error in my whole life, while pretty much all the other editors I've ever used did. While his code is old, it's certainly resilient.

    Open Vim. Type "1.02". Put the cursor on the 2. Hit C-x; get 1.01. Again; get 1.00. Again; get 1.01777777777777777777777.
- Gary Bernhardt (@garybernhardt)

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

#208

Post by VeejayRampay »

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.

What about being inclusive as an open-source code base? If you simplify the code, remove obsolete cruft and start making use of common place modern libraries, then all of a sudden a bunch of people who were not interested in the first place because the code was way too complicated to get into are suddenly an option. And that's huge.

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

#209

Post by im3w1l »

knodi123 wrote: post #114
brudgers wrote: post #71

Earlier quoted context omitted.

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

I remember I once went to great trouble to use a succession of old computers to copy my favorite DOS game off of a 5 1/4" floppy into a 3 1/2" floppy, and then from there onto a network, and then onto my laptop, so I could take it to school with me. And in the end, I learned that the game ran so fast on my laptop that your character would move at light speed and then die as soon as you pressed a button, because my la…

If you still want to play it, dosbox supports adjusting emulation speed.

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

#210

Post by cardinalfang »

firebones wrote: post #166
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…

It's been a long time since I've done bare C, but are there now IDEs/editors that let you toggle the define statements you want to activate which then format the code without the ifdef/endif cruft to let you better conceptualize the actual source?

Eclipse can colour or fold code within inactive preprocessor directives, but that may not be enough for this particular specimen.
Post reply on HN