Closed occivink closed 6 years ago
How about moving "
to <c-r>
?
Yeah, I'd be open to this change, I am not really keen on <c-r>
, but if we dont find better I could go for it.
I think this was fixed in bc0dfa9e8fe488a1847580b50fa39ad42a987dc2.
Not exactly, whats suggested here is that "
thats still used for register selection would be moved to something else, so that we can use "
for rotate selection contents, and <a-">
for rotate selection contents backwards.
This was not implemented because I am a bit weary of using <c-r>
to select the register, I'd like something not control based, but I dont know what. Or maybe <c-r>
is good enough, and has the merit of matching what we do in insert mode.
#
and ^
are still free keys as well.
I've come to like <c-r>
because register specification is not really a command in itself, so having it on a different binding makes sense.
Yep not a command in itself and match what we do in insert mode.
#
and^
are still free keys as well.
I like ^
, for some reason it seems even more adequate than the current "
, and it's also better than a modifier-based binding.
Other possible mappings with nice symmetry:
(
: rotate main selection backward)
: rotate main selection forward<a-(>
: rotate selections contents backward<a-)>
: rotate selections contents forwardWhich frees up the '
key.
Yeah, I think thats a pretty nice suggestion, any more opinions on that ?
Would love to hear opinions of other kakouners like @danr, @fsub, @Screwtapello, @ManDay, @nochiel, @aver-d on this issue so we can reach a conclusion about the new key mappings.
I like the idea of using the paretheses family for this purpose.
rotate main selection forward
is such a common operation, that I've been thankful it's just one key. Having to hold \<s-0> to rotate main might be a bit unfortunate (and \<a-s-0> to rotate selection contents would be painful at least for me (on a flat qwerty keyboard). A single keypress for common operations is often really nice and 2 keys combined for the dual operation is quite conventient. alt+shift+key combinations make me sad.
ps. @Delapouite Thanks for asking for feedback. Of course, being an emacs refugee, I can get accustomed to any key combinations. Kakoune is still less painful on the wrist than emacs afaic.
@Delapouite Thanks for asking, but my movement and transformation skills are too limited to make a qualified comment on this issue.
I find <a-">
pretty useful. So I already gave it a promotion to a nicer key. I won't say which one… introducing a further plot twist may mean never escaping the keyboard key labyrinth…
In any case, I agree that @Delapouite's parens idea looks a nice default – not that I'm sure I merit a place on the Kakoune board of executive directors.
As much as I do like flipping through selections by bouncing on '
without any modifier, ()
is probably a better mnemonic. While renaming "
to <c-r>
has precedent in insert mode, it would be a pretty hefty shift from the vi predecent that Kakoune still mostly follows, and likely to annoy a lot of people.
Thanks for your feedbacks!
II think the big underlying problem is broader and not really about which keys would fit better (but it's still a valid concern). The real issue is paradoxically what makes kakoune strength/simplicity (and vi legacy): a new normal command can't be introduced on the C++ side without being assigned a precious key on the keyboard.
The underlying implementation lays here: https://github.com/mawww/kakoune/blob/master/src/normal.cc#L1366-L1384 and the only way to expose it is through a key name like the current binding:
{ {alt('"')}, {"rotate selections content", rotate_selections_content} },
On user land there's no :rotate-selections-content
command. It's only known as <a-">
.
It may have already be talked about, but what about an complementary key naming? like <a-">
== <rotate-selections-content>
. Sure it's way longer, and not very practical in interactive coding. But in our case it could be useful:
1 - in C++, the rotate_selections_content<Backward>
is implemented.
2 - it is at least given the <rotate-selections-content-backward>
key name.
3 - users are then free to assign them how they want.
For instance following the <c-r>
example above:
map global normal <c-r> " -docstring 'registers'
map global normal " <a-"> -docstring 'rotate selections content forward'
map global normal <a-"> <rotate-selections-content-backward> - docstring 'rotate selections content backward'
Same strategy could be used for the parenthesis way.
Many fundamental questions stem from this idea. Should all current keys be retroactively given a long and keyboard independent name? Like u
-> <undo>
, x
-> <select-line>
…?
I remember that @alexherbo2 mentionned this idea once and @danr already tried something similar : https://github.com/danr/dotfiles/blob/a93c619decb8b741daa1c066f5ab2c027a2c3244/config/kak/normal-keymap.kak . The difference is, his script exposes commands
whereas I'm describing keys
.
There's already some kind of precedent with <mouse:wheel_up>
or <resize:18:42>
pseudo keys: https://github.com/mawww/kakoune/blob/master/src/keys.cc#L125-L149
@Delapouite fix incoming, using (
and )
. Regarding you naming suggestion, I would not do that as a way to add new functionalities without bindings. Having a 1 <-> 1 mapping between keys and normal mode functionality is a deep design decision of Kakoune that I do not plan to change.
I could however be tempted to introduce alternate names for those keys, mostly to make scripts much more readable. It seems pretty tricky to do though, because those key only have meaning in normal mode, and I dont think we would like to have <rotate-selection-backward>
insert a (
if we are in insert mode...
What's going to happen to quote based mappings?
They are freed
With
<a-'>
being recently added, I think it would be nice to have"
and<a-">
rotate the selections content forwards and backwards respectively, to mirror the behavior of'
and<a-'>
.Target register specification would have to be moved, but it's not like
"
is especially suited for this purpose.It's also not only out of consistency reasons that I'm proposing this. Recently I had a file that looked like this:
that I wanted to turn into this:
and it would have been simpler / more idiomatic (if only a little) to do that with backwards rotation.