Emacs C code is far better! And it's only ~22% c code instead of vim's ~66% reference: https://www.openhub.net/p/vim https://www.openhub.net/p/emacs
Note Emacs uses http://git.sv.gnu.org/gitweb/?p=gnulib.git to abstract away platforms differences
Vim's 400 line function to wait for keyboard input
161–170 of 239 posts
Re: Vim's 400 line function to wait for keyboard input
#162Earlier 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.
This was my biggest hurdle to learning vim, I kept hitting Ctrl-S...
This might help:
http://vim.wikia.com/wiki/Map_Ctrl-S_to_save_current_or_new_...
(Caveat emptor, can't speak from first hand experience.)
Re: Vim's 400 line function to wait for keyboard input
#163This 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 w…
It's also a case where making that investment is worth it given the core nature of the MSVC standard library which makes it integral to a universe of other software. The global impact of a 5x improvement in something in every app makes it a no-brainer. But there's a lot of debt out there that will be replaced before the payoff ever comes.
Interesting Fermi problem for sadistic interviewers: what would be the global energy saving per invocation of this vim function if a 5x performance improvement were to be found?
Re: Vim's 400 line function to wait for keyboard input
#164But 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…
Lots of people know and contribute to vim. If they try to make life easier for you, they will probably make life worse for all those who are already familiar with vim code. It is similar to the situation of the Linux kernel, where some people would prefer to use C++, while everyone who already works on Linux also knows and prefers straight C. Given the vitality of vim, I think you should just learn it and stop trying to change what already works.
Re: Vim's 400 line function to wait for keyboard input
#165Earlier 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 use it daily and it's been fine.
I use it with true color support enabled, and a terminal that supports true color, and a patched version of tmux that supports true color, and finally all color schemes render as they do in gvim!
Also the terminal emulator feature is awesome.
Re: Vim's 400 line function to wait for keyboard input
#166I'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?
Re: Vim's 400 line function to wait for keyboard input
#167Earlier 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]
Re: Vim's 400 line function to wait for keyboard input
#168But 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…
[deleted]
Re: Vim's 400 line function to wait for keyboard input
#169Earlier 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 it daily and it's been fine. I use it with true color support enabled, and a terminal that supports true color, and a patched version of tmux that supports true color, and finally all color schemes render as they do in gvim! Also the terminal emulator feature is awesome.
yeah, there is a good chance you'll not run into problems. however new, serious bug reports come in frequently. for example a lot of people have been seeing segfaults, and nobody seems to know where to look.
Although Neovim's codebase is significantly cleaner than vim's, its still a far cry from what I would call good.
Re: Vim's 400 line function to wait for keyboard input
#170I wonder how many examples there are of a more beloved UI (among coders) than Vim's keyboard input. For myself, its exceptional keyboard responsiveness is a essential part of what makes Vim feel so effortless, so hardwired to my brain.
I wish all code was equally buggy.