One thing that often throws me off when using Kakoune is how your cursor is moved to the beginning of your selection when pressing i, or the end of your selection when pressing a.
It’s fine if your cursor is already at that end, but if your cursor is at the end of your selection for example, and you press i, it jumps you to the beginning.
I tried turning this off with the following mapping:
# Drop selection when entering insert mode
map global normal "i" ";i"
map global normal "a" ";a"
I think I prefer this new behavior, but I’m wondering if I’m missing the point? Am I losing functionality by dropping my selection? Is there an intuitive reason why I would want the default behavior?
Obviously I won’t have the selection when returning to normal mode with <esc>, but I could probably save and restore it if I wanted (though I don’t really care).
Let’s say you’re refactoring some code, and a function that used to be at the top-level (say, do_a_thing()) is now in a submodule (as util::do_a_thing()).
The way Kakoune works by default, you can add the util:: prefix to every occurrence in the buffer with:
%sdo_a_thing\(<ret> to select all the mentions of do_a_thing() in the buffer
iutil::<esc> to insert util:: before each one
The s operator produces selections that go left-to-right; that is, the anchor is before the cursor. Once you have selections, you can insert before, insert after, or replace them with i, a, or c respectively. Remapping i to ;i removes one of those options.
I remember when I first learned Kakoune, it took me a while to transition from the Vim module of “sometimes you have a cursor, other times you have a selection” to the Kakoune model of “there is always a selection, but sometimes it’s just a single character”. It felt a lot like playing Snake or driving a car with a trailer attached - not just moving the cursor to the right spot, but also worrying about where my tail would be when I got there. It’s annoying when my tail is in the wrong place (but not too annoying, since ; is right there) but when I get it right it’s a real improvement.
I sometimes use ido_something(<esc>a) on a selection to call a function on that variable for example.
With your mapping you would lose this possibility.
However, you coud fix it by using Z to store the selections first.
Any remapping will add and lose some funcionality at the same time, everything is a tradeoff and YMMV. I use my editor for prose as well as coding, and like you, I find the default behavior of i and a to be visually annoying. Actually I go further than you, because when i have a word selected (for example), I think of i and a as inserting text before or after the word rather than before or after the cursor. So I use the following mappings:
map global normal i <a-:><a-\;>\;i
map global normal a <a-:>\;li
that do what I want regardless of whether the cursor is at the left or the right of the selected word.
As to losing the endpoints of the original selection, I can easily regain them by escaping to Normal mode after insertion (what you will need to do anyway), selecting the whole thing (= original selection + newly inserted text) quickly (I have further mappings for this purpose!) and pressing i or a again. Most of the time, the “whole thing” (beyond the original word) is a big WORD.
I now see (with kak -n) that your mappings are enough to do what you like! No need for the more complicated ones… But I still believe (like you) that losing the selection is no big deal.
But I was wrong – yes, the more complicated mappings are better (at least if you want to do what I want!). The problem with your mappings is that the ; key reduces the selection to a single cursor before adding new text, so the position of the new text will depend on the position (side) of the cursor within the original word.
Damn–I should take a rest–working too hard on a plugin
