First, to (hopefully) prevent misunderstanding, the author says clearly that visual mode is sometimes useful. In particular, he writes that you may want visual mode to “Visually confirm the text you are going to operate on.”

That said, I think it’s interesting that (as I understand it), Kakoune and Helix have deliberately gone entirely in the other direction.

From Kakoune’s migrating from vim page:

Operations and moves are reversed in Kakoune. First select whatever text you want to operate on, and then use a modifying operation. That makes things more consistent (Vim needs a separate x and d operation because of the operator -> move order, Kakoune only needs the d operation). That also allows more complex selections.

From Helix’s migrating from vim page:

Helix’s editing model is strongly inspired from Vim and Kakoune, and a notable difference from Vim (and the most striking similarity to Kakoune) is that Helix follows the selection → action model. This means that whatever you are going to act on (a word, a paragraph, a line, etc.) is selected first and the action itself (delete, change, yank, etc.) comes second. A cursor is simply a single width selection.

I’m a longtime Vim and Neovim user, and I haven’t used Kakoune or Helix enough to have a strong opinion. But I wonder what people think about these choices. (I’m especially curious to know what people think if they migrated to Kakoune or Helix from Vim or Neovim.)

The way I stop running commands like

Vkd

and replace them with

dk

is, when I do the former, I catch myself after the fact, undo the change, then do it again the faster way. It obviously takes longer to do it twice, but pays off because after only one or two repeats for a pattern I start doing it the more efficient way from then on.

In the end vim is just a software and most of its behaviour is predictable. However I have never been able to convince myself to use sequences like dk because I mistype a lot. Overusing visual mode helps me see the selection that following command is going to work on. This is the premise of the grammar of editors like Kakoune and Helix. I don’t really care if I could do it in 2-3 fewer keystrokes. But I value more that I know what the next keystroke is gonna do.

Somewhat disagree. If you’re trying to learn and visual selection is becoming too much of a crutch, then by all means, use that hardtime plugin to keep you on your toes. But once you’re settled in, please feel free to use visual selections as much as you want; especially in situations that involve manual counting, like in the given example V5jd (selecting the next five lines …); it’s relatively more taxing to manually tally up a count to act upon (with relative numbers enabled or not) than it is to just go down visual selecting, and you can’t deny the assurance of a visual feedback, especially for destructive operations.

BTW another benefit is if you happened to make a mistake while visual selecting your target (like in counting those 5 lines), then gv brings up the most recent visual selection and you can re-target again. If you would’ve asked me when I was learning all those years ago, I would’ve agreed with the post but now I just want to do things the most easiest way possible, that’s where I’m coming from I guess.

That said, there is a suggestion to be made: use text objects as much as possible, get a plugin if you have to. That should lessen dependance on visual selection and increase your ability to target with more ease and clarity.

Going to add that plugin suggested here. I wonder if things like textobjects could help as well. I find them useful when I’m aiming to link to some code but want to get a specific range. A lot easier and direct than holding down or up a few times (or j and k for the more purists, lol).

Maybe people already know this, but (at least for yanking) there is a compromise between visual-first and no feedback.

• For Vim, you can use vim-highlightedyank.

• For Neovim, you can use the builtin vim.highlight.on_yank in an autocommand.

    vim.api.nvim_create_autocmd("TextYankPost", {
        pattern = "*",
        callback = function()
            -- You can put whatever highlight group you like in higroup.
            -- Ditto for the timeout length.
            -- See `:help vim.highlight.on_yank()` for more options and details.
            vim.highlight.on_yank({ higroup = "Visual", timeout = 300 })
        end,
        group = vim.api.nvim_create_augroup('highlight_yank', {}),
    })
  

This is a good reminder to reconsider habits in general when it comes to working in vim. I’d admittedly do kdddd before thinking of something like dk or Vdk. It’s really easy to get stuck in your ways with an inefficient workflow because it works well enough to get by.

As someone who switched to kak 5ish years ago after having been an evangelical vim user since college and never looked back, this article did a great job of reminding me why. Even the “better” versions from this article are longer tgan what I’d use give no feedback until fully executed and feel weirdly lacking in flexibility (id forgotten that something like ‘dk’ignores column position, and that feels wrong now) and I’m not exactly a wizard.

Edit: I guess % is a thing in vim and the author may not have known.

In general, the advice is that any range that you can define in visual mode can be passed directly to a command (I don’t believe this is true of visual block mode) and that’s a good thing to remember. I mostly use visual mode for uncommon operations because it comes with a free preview: I know exactly the text that’s going to be modified because it’s highlighted. With unlimited persistent undo, that’s perhaps less important than it was, but it still helps reduce surprises.

[Comment removed by author]