And I mean ‘c’. I use it all the time except when the entire file or selection fits on the screen. Which is not often in larger files. For non-vimmers, c causes an old-school confirmation prompt with yes/no/all/abort.
I understand kakoune is an experiment much like vis was (it looks inactive). I value kak for this because it’s high time other editors started learning from vim, and vim does have some poorly designed features. IDEs are learning from Emacs. I use neovim myself.
Color me skeptical about the whole multi-selection thingy. I think it works spectacularly (and ‘spectacular’ is the keyword here) for simple cases, but poorly for bigger ones, let alone advanced ones. I’m talking about a file with a few hundred lines of fairly unstructured code (not over 4000 of crap I deal with at work). There’s just no sensible way to deal with multi-selections that don’t fit on a screen!
Confirmation is very useful because it’s common to not get it perfectly right at the first time in a file that had a few authors. And there may be something you haven’t thought about. Confirmation prompt lets me skip a search&replace match or completely abort if I realize I made a terrible mistake. Kakoune effectively forces you to get it absolutely right the first time. And if you use regex, you better look at all your matches immediately because as soon as you press c they’re completely gone and you can’t see what was there.
The only way I found to re-view my search results before I nuke them is select first, then loop over with )(. I think this is putting the cart before the horse and more error-prone.
You can have great screenhots and trailers for a poor game. I think there are many games optimized for screenshots, not for playing. I think multi-selections are one of those things. It’s the same reason I take vimcasts.org with a grain of salt. Many of that guy’s tips seem optimized for showing off, not for practical work. I mean, whyYy would I want to move some lines up 1 line at a time instead of pasting them right where they belong. And pollute change history at the same time.
Another - in my eyes - advantage of vim’s approach is that it’s trivially repeatable by default, and trivial to edit as well. The problem with overly interactive programs is that you can’t script them easily, and vim sorta hits a good compromise between interactive and scriptable. When I type a comand, I don’t see selections as they change, but I see ahead what will happen later. Sometimes it works well, sometimes not so much. Either way having easily editable and reviewable commands encourages editor users to do just that, instead of using a “good enough” combination of keys that requires manual fixing afterwards.
Bonus: I have this in my
# This modifies UPARROW and DOWNARROW keys to supply commands from # bash history file using INCREMENTAL SEARCH. "\e[A": history-search-backward "\e[B": history-search-forward set show-all-if-ambiguous on set completion-ignore-case on
This is for readline, not for vim. It works in Bash, in vim command mode, in python interpreter. Note this is not a nice way editor pieces fit together, just a nice way an operating system pieces fit together. And a couple of keys shorter than kakoune too.
Vim commands combined with search history mean that :command (ex?) mode is a bit like my spellbook. Usually I only have to type the first few characters of a command, uparrow, enter.
I’ll post more complaining in next threads, but this was a low hanging fruit (and I’m quite sure I know this part of kak well enough not to make a fool of myself).