Neovim: Rewriting & Modernizing The Vim Editor

[dante]

It is ironic that they are rewriting vim "for the 21st century" in C. I looked over their new code, not seeing the old vim code, and I wasn't really impressed. The old vim code must have been horrible.

Too make a application lightest as possible C is still unbeatable today .

[rdnetto]

The apps, or the users?

I can't really argue with you. I use Vim because I'm used to it. I can't really make a very good argument for it on its own merits.

People try to argue that it's more efficient, but when you compare "delete word", which would be "d, w" in Vim or "Shift+Ctrl+Right, del" in other editors, or "go to line 255", which would be "255 g" in Vim or "Ctrl+g 255 Enter" in other editors, the efficiency edge is slight at best. And in other editors, you can discover functionality by browsing the menu; in Vim, you have to read through the manual to discover functionality.

Where Vim really shines is repeated actions and text objects. If you want to delete the next 5 words, it's just 'd5w' (or '5dw'). If you want to delete the entire line, it's just 'dd'. Delete up to and including the next comma (useful for arguments in C), it's 'dt''. Changing the contents of a string is 'ci"', and so on and so forth. In most editors, the equivalent keystrokes are repetitive and take much longer.

I agree that the learning curve is steep. That said, everything described in the above paragraph is covered in vimtutor, which takes about half an hour to get through and is well worth it. Vim cheatsheets are also a great resource when you're new to it. I do think the default settings could be better though (e.g. "set nocompatible" should be enabled by default, otherwise you're missing out on 22 years of progress).

Having said that, vim does need some re-factoring. E.g.:
The existing scripting language should be slowly phased out in favour of something mainstream (Python?), the GTK front-end is showing its age and in need of refreshing, etc.

Neovim is pushing Lua as a replacement to Vimscript, as it is apparently quite fast when JIT'd.
Take a look at vim-qt - I've found it works much better than GVim.

Too make a application lightest as possible C is still unbeatable today.

Rust looks like it could change that - it has the same low level focus as C, but a much nicer (optional) runtime and implicit memory management.
That said, I suspect the main reason for writing Neovim in C is the desire to not fragment the codebase too much, so that there's the possibility of merging the changes back in.

[Skrapion]

If you want to delete the next 5 words, it's just 'd5w' (or '5dw').

True, that's fast, if you know exactly how many words you need to delete.

Another similar example is < and > to change indentation. But I find that most of the time I don't know exactly how many times I need to (un)indent, so I select a block, guess at the number, and then reselect and repeat until I get it right. Not terribly efficient. In other editors, I select the block and I just tap Tab (or Shift+Tab) until it's right. Vim loses that battle.

Now, things are a little different if you're doing a repetitive task, and you happen to know that you need to delete exactly five words over and over again. In that case, the speed of typing "5dw" doesn't actually make a huge difference in Vim, because you're just going to use . to repeat the last command. This is analogous to using a macro in other editors, so no huge advantage here either.

If you want to delete the entire line, it's just 'dd'.

Yep, I use that one quite a lot. But in other editors it's as simple as Home, Shift+End, Del. Sure, it's one or two extra keystrokes (depending on whether or not you were already at the beginning/end of the line) but how often do you do that? In Vim, we're constantly typing i and Esc just to type regular characters, and I certainly do that more often than I delete lines.

The difference gets even tighter when you're deleting multiple lines. Let's say you're deleting two lines. In Vim, that's 2dd, or dddd. In other editors, it's Home, Shift+DownX2, Del. Only a slight advantage at that point. And once you have enough lines that you can't easily count them? Then you just hit Shift+V to go into visual mode, and in that case Vim incurs an extra keystroke.

Delete up to and including the next comma (useful for arguments in C), it's 'dt''. Changing the contents of a string is 'ci"', and so on and so forth. In most editors, the equivalent keystrokes are repetitive and take much longer.

Okay, I didn't know those ones. Actually, I just tried them, and dt' doesn't seem to work (looking in the manual, perhaps you meant df,). Typically instead of ci" I would use d/"<Enter>i. Admittedly, even that is significantly faster than anything I've seen in any other editor.

Although, it doesn't need to be that way. It would be pretty trivial (and useful!) for other editors to implement something like Ctrl+d " to delete up to the next quote, or Ctrl+Shift+d , to delete up to and including the next comma.

I would also be far more likely to discover this on my own if it was a shortcut listed in a menu, rather than not having discovered it until somebody tells me about it on some forum fifteen years after I picked up Vim.

[rdnetto]

True, that's fast, if you know exactly how many words you need to delete.

And if you don't, you just use EasyMotion.

Another similar example is < and > to change indentation. But I find that most of the time I don't know exactly how many times I need to (un)indent, so I select a block, guess at the number, and then reselect and repeat until I get it right. Not terribly efficient. In other editors, I select the block and I just tap Tab (or Shift+Tab) until it's right. Vim loses that battle.

. should repeat that. Alternatively, you could just map tab to do that.

Now, things are a little different if you're doing a repetitive task, and you happen to know that you need to delete exactly five words over and over again. In that case, the speed of typing "5dw" doesn't actually make a huge difference in Vim, because you're just going to use . to repeat the last command. This is analogous to using a macro in other editors, so no huge advantage here either.

I'd argue that . is more similar to redo, or at least an extension of it that a few editors implement. Vim's macro support is more powerful.

Yep, I use that one quite a lot. But in other editors it's as simple as Home, Shift+End, Del. Sure, it's one or two extra keystrokes (depending on whether or not you were already at the beginning/end of the line) but how often do you do that? In Vim, we're constantly typing i and Esc just to type regular characters, and I certainly do that more often than I delete lines.

The underlying philosophy in Vim is that all of the common edits should be fast. Sure you might not delete a line or two that often, but I bet if you were to make a list of the 20 or so most common edits you perform, they'd all have very concise expressions in Vim.
If you're just using 'i' to enter insert mode, then you're not taking advantage of the commands which combine the mode change with another movement or edit. e.g. all the change commands delete text before changing the mode, 'A' moves the cursor to the end of the line first, and 'o'/'O' creates a new blank line below/above the current line first. (That last one is particularly useful.)

The difference gets even tighter when you're deleting multiple lines. Let's say you're deleting two lines. In Vim, that's 2dd, or dddd. In other editors, it's Home, Shift+DownX2, Del. Only a slight advantage at that point. And once you have enough lines that you can't easily count them? Then you just hit Shift+V to go into visual mode, and in that case Vim incurs an extra keystroke.

Refer to my comment on EasyMotion.
Also, relative line numbers are extremely helpful when using such commands. (The latest version of Vim can also show the current absolute line number in place of 0 for relative numbers.)

Okay, I didn't know those ones. Actually, I just tried them, and dt' doesn't seem to work (looking in the manual, perhaps you meant df,). Typically instead of ci" I would use d/"<Enter>i. Admittedly, even that is significantly faster than anything I've seen in any other editor.

You're right, that should have been 'df,'.

Although, it doesn't need to be that way. It would be pretty trivial (and useful!) for other editors to implement something like Ctrl+d " to delete up to the next quote, or Ctrl+Shift+d , to delete up to and including the next comma.

'Ctrl+d ,' would have the same issues with discoverability - in fact, it sounds like Emacs command. (The actual Emacs command for this is 'Meta-z ,', which makes sense given that they use the term zap instead of delete.)

I would also be far more likely to discover this on my own if it was a shortcut listed in a menu, rather than not having discovered it until somebody tells me about it on some forum fifteen years after I picked up Vim.

I agree that the discoverability is terrible. I don't know how well a menu-based approach would work as a lead-in to conventional vim. Part of the problem would be that shortcuts are faster on keyboard (e.g. 'dtf,') would likely take so much time to select from a menu that they wouldn't be worth using compared to just selecting the text with the mouse (which currently works in Vim-qt).
Vim-qt (not sure what Gvim is like) does have several commands in its menus, but these are mostly things like save, copy, print, as well as more obscure options relating to syntax settings.

I think that Vim is best learnt the same way you a learn a programming language, rather than an application. Each edit is effectively a very short program, and when you're experienced in it it becomes second nature, like shell commands. There's a great book called Practical Vim from the author of the vimcasts site that has loads of info in it, and should probably be regarded as recommended reading after completing vim-tutor.

[bnolsen]

Too make a application lightest as possible C is still unbeatable today .

Compiling 'c' with a c++ compiler to get better type checking, etc. Add namespaces and some other features, while avoiding virtual classes, template libraries or exceptions is probably the best compromise from the programming side. C definitely has some issues on both the scalability and correctness side, although I think the newest 'c' standard may have added a few helpful correctness type things.

[chrisb]

True, that's fast, if you know exactly how many words you need to delete.

Another similar example is < and > to change indentation. But I find that most of the time I don't know exactly how many times I need to (un)indent, so I select a block, guess at the number, and then reselect and repeat until I get it right. Not terribly efficient. In other editors, I select the block and I just tap Tab (or Shift+Tab) until it's right. Vim loses that battle.

V followed by j (or k) to select your block, then > and keep hitting . until you are happy.

If you don't know how many words to delete, then use a pattern eg. d/xxx will delete upto text xxx, dfx will delete on current line up to letter x, etc. Use full stop to repeat.

Yep, I use that one quite a lot. But in other editors it's as simple as Home, Shift+End, Del. Sure, it's one or two extra keystrokes (depending on whether or not you were already at the beginning/end of the line) but how often do you do that? In Vim, we're constantly typing i and Esc just to type regular characters, and I certainly do that more often than I delete lines.

Vim wins if you don't want to be slowed down by taking your hands off the keyboard to relocate the pointer. With vim you can relocate anywhere, say to xyz with /xyz (forward) or ?xyz (back), then hit n or N to jump again. Use v or V to block select and then do the same e.g. v/xyz or V/xyz then you don't have to count lines, you just use text strings in the lines to identify them. /syn<enter>V/san<enter>d to delete all lines from the one containing syn to the one containing san. No mouse required (in fact, I always install vim-nox).

:vsp for vertical split is something I almost always use when coding. How many other editors allow you to simultaneously view/edit two windows on the same file? (Last time I looked at Eclipse it had got vsplit but not on same file)

Remap -/spacebar to pageup/pagedown. If you find yourself paging up and down through code a lot it saves much time over the regular page up/down keys.

Remap caps lock to escape. Using it in vim is no big deal, it's just like putting a full stop at the end of a sentence.

Use exuberant-ctags. Just do ctags -R in your project directory to recursively scan the source, then open vim, move the cursor over a function call or variable, hit ctrl-] to jump to definition, ctrl-t to jump back. :ts x to search for tag x. Some might say it's not as good as proper dynamic code browsing, but it's really fast and because it's simple it always works, even on large projects with build systems, preprocessors and dynamic code that Eclipse's language parsers fall down on. Try ctags and vim on the Linux kernel, it's fast and works, even though the kernel source is huge and there are multiple definitions of symbols. Now try doing that in Eclipse and see how far you get.

Also useful: terminator. ctrl-shift-e to vsplit the terminal ctrl-shift-o to hsplit it. I seem to constantly need extra/temporary terminals as I work. set scrollback_lines to something big, like 5000, it's always good to be able to scroll back (shift pageup) as far as you need.

[gilboa]

Neovim is pushing Lua as a replacement to Vimscript, as it is apparently quite fast when JIT'd.
Take a look at vim-qt - I've found it works much better than GVim.

Thanks for the head's up.
I was under the impression that vim QT port was dead...

- Gilboa

[pingufunkybeat]

Another similar example is < and > to change indentation. But I find that most of the time I don't know exactly how many times I need to (un)indent, so I select a block, guess at the number, and then reselect and repeat until I get it right. Not terribly efficient. In other editors, I select the block and I just tap Tab (or Shift+Tab) until it's right. Vim loses that battle.

Just press "=" instead of ">", and it will automatically indent your selection correctly.

Or you can go anywhere in a block of C code and type "=i{" and it will indent the entire code block between curly braces.

I agree that these commands are painful and insane and at the wrong side of the "reasonable" spectrum, but Vim is a programmer's editor, and if you spend most of your time programming, it is a great investment, especially when combined with its powerful scripting for things like refactoring, code completion, commenting, regular expressions, etc.

[rdnetto]

Thanks for the head's up.
I was under the impression that vim QT port was dead...

- Gilboa

No, it's still active. The update for Vim 7.4 came out within a month of the upstream release.

[znby]

He's managed to raise over $30k on Bountysource, here's hoping that he does something good with all that money

https://www.bountysource.com/fundrai...e-21st-century