4 ms·

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perfo

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case. Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.). As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better. That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.

oblio 3y ago
> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds. I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ). Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.
- turboponyy 3y ago
  This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked. The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one. Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers. For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine. Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs. The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
- mdtusz 3y ago
  Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.

oblio 3y ago

> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds. I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ). Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.

turboponyy 3y ago
This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked. The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one. Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers. For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine. Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs. The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.
mdtusz 3y ago
Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.