It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…
I want to use Helix but can't until it supports running external commands.
Vim Language, Motions, and Modes Explained (2023)
51–60 of 104 posts
Re: Vim Language, Motions, and Modes Explained (2023)
#52I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in. My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if…
You can absolutely change the keybindings, vim is programmable.
Re: Vim Language, Motions, and Modes Explained (2023)
#53I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point. Take, for example, writing a for loop. I might type: for…
Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.
Re: Vim Language, Motions, and Modes Explained (2023)
#54It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…
The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.
I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
Re: Vim Language, Motions, and Modes Explained (2023)
#55Here come the "[..] anyway I'm happy with VSCode" comments
I feel like those trying to teach me Vim are the same who refused to learn to use VsCode. Once configured, I can do the same than Vim. With more features.
Re: Vim Language, Motions, and Modes Explained (2023)
#56Yes, it’s super handy to be able to record an Emacs macro and modify large text within seconds, something that would take me half an hour. Yes, it’s super cool to navigate text at lightning speed. But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Beca…
Re: Vim Language, Motions, and Modes Explained (2023)
#57It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…
There are also plugins that shows a pop-with with available keybindings if you want.
Re: Vim Language, Motions, and Modes Explained (2023)
#58One thing I really appreciate about Vim is that it just opens. And I don't mean speed, I mean not getting bunch of pop-ups nagging me to do something about a configuration, extension, feedback or whatever. I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.
May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.
Re: Vim Language, Motions, and Modes Explained (2023)
#59Earlier quoted context omitted.
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point. Take, for example, writing a for loop. I might type: for…
I think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice. Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.
https://github.com/susam/uncap
While it was certainly possible to do that by editing Windows registry (and I have noted those techniques too in the README), registry changes couldn't be enabled or disabled without a reboot. That's what motivated me to write the above tool. And indeed, having the Caps Lock work like Esc made using Vim a much better experience!