Change slightly how `x`/`X` works
dpc opened this issue · 74 comments
Right now: https://github.com/mawww/kakoune/wiki/Migrating-from-Vim states, that to "copy a line", one has to do xy.
That's however is technically not true. Because if you're on an empty line, you are going to copy the next line. My point is not that Wiki is wrong, but that to reliably select a current line, one has to use <a-x>, so that reliable "delete current line" is <a-x>d which is way less convenient, especially comparing to very handy dd in Vim.
While I really appreciate the "visual feedback" of Kakoune, and I think it's amazing when doing anything non-trivial, having to rely on the visual output, while doing trivial and mechanical operations like deleting lines is terrible. The fact that I have to pay attention to exact content of everything just so I don't delete a different line is just slowing me down.
Edit: Also, not that x is practically unusable for scripting. If your script needs to select a line somewhere, it has to go with <a-x> as the only reliable one.
I am aware that x/X needs to extend down and I also believe it's undesirable to loose that property.
So I was wondering if instead of the rule "x/X goes to the next line if the cursor is on LF and already selects the whole line" the new one: "x/X goes to the next line if it previous action was also x/X`" wouldn't be better?
This way first x reliably selects the current line, and following ones move downwards. Everything becomes trivially predictable. The behavior of the movement would be conditional only on the keystrokes of the user.
This change should be quite easy to get used to for the existing users. In case they press x/X while having a whole line selected somehow without using any x command (typically because of being on an empty line), they will just have to press x/X again. It would be awesome if some form of visual change was there, but it's not terrible if it isn't. Maybe there could be a special color or some other visual designation for the "full-line quasi-mode" that one enters after first x and leaves after first non-line command, which would make the whole thing obvious.
Note: Any line-related command (xX<a-x><a-X>) should work for any line-related command for the purpose of "consecutiveness".
BTW. If the above idea/paradigm of actions having a tiny bit (actually precisely one bit!) of memory is accepted, then it would make sense to improve <a-x> and <a-X> slightly. Right now they are idempotent, which is not very useful. But they could work somewhat analogous and subsequent <a-x> could extend selection by one line on both top and bottom of the current selection(s), and subsequent <a-X> could shrink it. This could be used for "select full-lines of the current selection and add/remove N before, and N after it".
This way all the x key variants become quite nifty tools for selecting many lines visually, which is awesome because line-based operations are bread and butter of code editing. For perfection, one would need just some way to extend only upwards or move the whole selection one line in a given direction. That would allow selecting any range of lines by staring just somewhere in the middle and extending up/down by pressing x-variants. I guess, due o running out of x-key combinations, some other key could be used.
Hmm... crazy idea... maybe if we follow the logical model of "full-line quasi-mode" that one enters after x-and-alikes, then even some existing keys/movements could do something similar to what they do right now, but in a line-oriented way. Eg. J effectively extends selection downwards, so maybe it could extend or move full-line selections downward, and K could extend or move full-line selections upward. Just thinking aloud.
I'm trying to implement it here: https://github.com/dpc/kakoune/tree/line_editing
I think I've succeeded. https://github.com/dpc/kakoune/tree/line_editing
This does not add any visual feedback, or implement any of the "extension" ideas. If I mange, I will try to implement it.
I probably do a terrible job at it, but I'm trying out the more extreme ideas here: https://github.com/dpc/kakoune/tree/line_editing_bells_and_whistles . Please read commit logs for instructions.
I tried line_editing branch and it's quite interesting experience, I think I'm gonna use it at least for another few days.
I definitely recommend others who are reading this thread to try it for yourself.
My "bells and whistles" is almost ready.
I wish I could get the selection to change color after one enters "line selection mode" for both the "conservatie" and "bells and whistles" branch. Then it would all be obvious, and quite pretty IMO.
I'm thinking about re-implementing your line_editing branch in kakscript, I like your approach and personally I'd like to continue using it, but I'm concerned it will be difficult to convince everyone to change the default behavior, and maintaining a fork is kinda annoying.
@maximbaz Better than nothing. :) . I still hope that after trying it out, more people will be convinced.
Maybe because I wasn't using kakoune for very long yet, but with vanilla kakoune even though I understand the logic in how x behaves on empty lines, very often I still hit XXX one too many times and then adjust my selection with K. It has even become a habit that I didn't think about until yesterday, but it's sad to have such habit in the first place. With line_editing branch my selection is always precise, because the number of times X needs to be pressed is predictable.
I would be guessing that long time users have internalized the current rules, and they just avoid pressing x on empty lines altogether, so they won't really feel a difference much if at all. New users who haven't internalized "working around" the current logic should feel an improvement.
After a day with this change, the biggest problem with my Kakoune experience is totally gone, and line-wise I am always precise. I still feel that yy, dd are slightly more convenient because they repeat the same key, but obviously it's impossible to get it in Kakoune's model, and I think Kakoune model is better overall.
Note: I'm using my line_editing_bells_and_whistles branch, where <a-X> and <a-x> are no longer idempotent, but start shrinking/extending the selection, and HJKL in "full-line selection" was modified to allow nice control. I don't have strong feelings about these additional changes. They not as "life-changing" as being able to select lines precisely without paying too much attention.
Now the last problem with getting used to kakoune is anchor vs cursor ordering. And I think I just need to modify the colorscheme to make the cursor more distinct vs the selection.
That's also one part that I don't understand how to handle in line_editing. When doing consecutive x-s, must the cursor always be below anchor, and should command like <a-;> be allowed to preserve the x-s "consecutivness"? It seems to me that in the current rules: the fact that cursor has to be below anchor was artifact of how the logic worked. With my change, this limitation is no longer neccessary, but as a noob I don't fully realize if it makes any difference.
I picked up using <a-x>XXX... somewhere. This works, but is awkward. I think I'll try this out a bit later.
Looks like a glass half-empty/half-full issue, you'll prefer x or a-x depending on which you already use the most.
The easiest thing to do is revert the two mappings in your user configuration, that works for everybody.
@lenormf I thought like this at the beginning, but it doesn't solve anything. <a-x> doesn't go downwards. So you loose ability to xxxx to go down with line selected. And you have to do xXXXX for predictable extending lines.
With my change you can predictably do xxxxxx or XXXXXX, depending on what you want, because it fixes the fundamental problem that in Kakoune there's no way to differentiate "being on an empty line" and "having a whole line selected". They are just conflated, and rationalized away.
You can think of my change as introducing a difference between "selecting all characters in a line" and "selecting a whole line". The first time you hit x or X you select the line as a whole. So if you were on an empty line, it looks the same, but it is different. If I had more time or kakoune knowledge I would actually implement some visual difference to make it clear.
I'm thinking, right now when you select lines it looks like this
foo.
.
bar.
Where . are invisible, but highlighted as all other characters.
What if it looked like this:
foo........................................
...........................................
bar........................................
This way when you first hit x or X on a line, you can see that you selected and highlighted the whole concept of a line - going to infinity (to the right edge of your window).
This way x/X on an empty line has a visual feedback, and makes it immediately obvious when your movement looses the line selection, and goes back to selecting bunch of characters.
@Screwtapello Thank you!
I've implemented it and pushed in line_editing_with_highlight branch. I think it looks and works OK. It doesn't even seems that noisy. I've also rebased line_editing_bells_and_whistles on top of it now, where it makes even more sense.
Couple of things to polish:
- what should the rules of anchor vs cursor be; should anchor always < cursor when working on full lines, or should we just preserve it? In case it's fixed, is there any point in displaying cursor highlight? And if yes, should be at the end of the "virtual line"?
- Which operations should preserve the line-mode? I've just noticed, that I would like
selectto potentially select all lines matching given regex, and keep the line-mode.
Just to repeat : "line editing quasi-mode" is an extension to the core idea of changing how x/X works. One could always explain the new behavior with just "goes down only if consecutive" and call it a day. I'm just experimenting here. :)
line_editing_with_highlight feels weird to me because it's specialized for x/X, for example here's how XXXK behaves:
@dpc found a serious downside of this approach, with your branch it is impossible to make the following binding work (to make X always extend down), because <a-:> is resetting the "previous action was also X":
define-command -hidden -params 1 extend-line-down %{ execute-keys "<a-:>%arg{1}X" }
map global normal X ': extend-line-down %val{count}<ret>'
Pressing XXX does not select multiple lines.
@maximbaz : line_editing_bells_and_whistles implements K and friends (though I'm not sure if in a way you would like it - but it can be changed). It feels much more natural there, but as I said - if this was to take approach of a full conceptual "line editing mode", it might need even more commands that make sense in line-only mode implemented. Give it a try and tell me what you think.
@maximbaz I don't understand why would you need this mapping now, as XXXX just does what you want by default. Maybe you just need to disable this workaround macro that is no longer need and is getting in a way.
But I've mentioned before that I think I <a-;> and <a-:> should probably be added to commands that don't enter line editing, but do preserve it. Similarly selection on line granularity makes sense now.
I made a recording of how it looks: https://asciinema.org/a/213645
I'll reply in full later, but to explain you the need for this macro, try selecting with KKKK and then pressing X - I want this to continue expanding selection.
@maximbaz If you did JJJ and then XXX that would work. KKK and JJJ is kind of a bug, which could be addressed by thinking through the previous question I posted above:
what should the rules of anchor vs cursor be; should anchor always < cursor when working on full lines, or should we just preserve it? In case it's fixed, is there any point in displaying cursor highlight? And if yes, should be at the end of the "virtual line"?
So: I agree with your desired behavior, and this can be easily fixed.
@maximbaz Like this? https://asciinema.org/a/213654 . I've pushed it in line_editing_with_highlight and line_editing_bells_and_whistles, though I tested more in the later.
Yes. Let me give you the full picture of how I'm currently trying to get kakoune's mappings to work for me:
xto extend down regardless of the anchor (likeXin yourbells and whistles)Xto extend up regardless of the anchor (likeKin yourbells and whistlesafter selecting something withx/X)KandJto remain as they are, because I use them to fine-tune selection (if I selected one too many lines down, I pressKto "unselect" the last line)- I have no mapping for the default behavior of
x.
This I can achieve today even in master, except that x/X are not consistent on the empty lines. So really for me your line_editing branch is perfect if your add the fix for <a-;> and <a-:> to it.
Fix for <a-;> and <a-:> was easy, so I pushed it. I think s S and <a-s> should also be changed, but the logic there is more complex and I don't have time right now. I'll get back to it.
@maximbaz X extends down regardless of anchor in bells and whistles (and all my branches now, iirc)
K and J to remain as they are, because I use them to fine-tune selection
In bells and whistles all HJKL can be used for fine tuning, quite flexibly, IMO. Anyway - there is plenty of possibilities on which keys and how exactly should work in combination of "line selection mode". The first question is rather: do other people like the "line selection mode" at all, and does it have a chance of landing upstream. If yes, then we can bike-shed, if not, then I'm just going to set it the way I feel like it, since I might be maintaining a personal fork anyway. I feel strongly that the changed x and X behavior is much better than original, but other ideas - I don't have strong opinions on. They look kind of cool and make sense to me, but that's just me maybe.
Recording: https://asciinema.org/a/213671
I like the proposal. The line editing mode is nice, so you have my +1.
However, while I feel like Alt x to grow up and down, and Alt X to shrink up and down too much, there is no command to exit line editing.
How about Alt x to toggle line editing, and Alt X to ensure entering?
@alexherbo2 Thanks. I'm not sure if I understand. I think you accidentally a word somewhere. Do you mean that with new behavior of <a-x> and <a-X> you miss the fact they don't finish the "line selection mode"?
Yep. Once we have our lines selected, we can’t go back with the non-line editing H J K L for fine-tuning selections.
So really for me your line_editing branch is perfect if your add the fix for <a-;> and a-: to it.
Fix for <a-;> and a-: was easy, so I pushed it.
Not sure if you pushed it to line_editing branch on which the open PR is based, I still have this issue with <a-;> and <a-:>.
@alexherbo2 So you'd like to a way to turn of the line mode, so that you can add a half-lines etc.? I kind of like the current <a-x> and <a-X> as it's quite well integrated. I'll think about what could be done about itt.
@maximbaz Yeah, line_editing contains only bare minimum ATM.
I see, so if the proposed behavior in the open PR doesn't work with <a-;> and <a-:>, I can't support this change because it breaks my setup.
@maximbaz I've just pushed it. I can pretty much cherry-pick each particular behavior between the branches, so it's just a matter of getting consensus.
Thanks - sure, but while this discussion is full of ideas I want to make sure your PR with "minimal wanted features" is complete and fully tested so that by the time mawww tries it, it is in a perfect shape :) I want it to be super convincing.
I just tried, still have an issue. Turns out, running a command also breaks the x/X to go to the next line. For example, press x, then press :echo hello<ret>, then press x again.
This is important in case people like me remap x to a command, i.e. this doesn't work in line_editing branch:
define-command -hidden -params 1 extend-line-down %{ execute-keys "<a-:>%arg{1}X" }
map global normal x ': extend-line-down %val{count}<ret>'
@maximbaz Yeah, I am actually looking into it. I still don't understand the details of even loop and modes here. Also, I wouldn't be too concerned about it. Chances are the way I implemented stuff is not great, and mawww will just have to tell me what to do instead.
I confirm the awesomeness of your branch 👍 And yeah, sure, it's totally okay to expect changes in implementation, but now I'm happy that your PR demonstrates the 100% expected behavior, no matter how it is implemented. Really hope we get some attention on it.
The nice property of it is that a single test haven't been broken, which tells something about how marginal of actual change it is.
In case anything else crosses your mind, please let me know.
I've changed names of the other branches. It is now:
line_editing- conservative, minimal changeline_editing_highlight- the above + highlighting the whole linesline_editing_ext- the above plus all the other changes (<a-x><a-X>HJKL, some other minor...)
I like the new way of how x is working, but I don't really see the point of extending highlighting to whole terminal width.
Extending selection vertically would be a nice feature, but I guess a syntax aware plugin for this already exists.
@dpc Alt x and Alt X are important features lost.
Alt x → Expand selections to contain full lines – including end-of-lines
Alt X → Trim selections to only contain full lines – not including last end-of-line
@alexherbo2 So you're saying that <a-X> used to not select end of line for the last line? Did I break it in line_editing too? I see. Well, could be restored, no big problems with it.
Since @mawww did buy into the idea, I guess I'm just going to maintain these changes in a fork, until x is fixed or something better comes along.
I've renamed and branded my repository as a fork: https://github.com/dpc/kakoune-dpc/
Do you think a solution can be found in kakscript, so you don't have to maintain a fork and keep using upstream? (I know I wanted to look into it myself, but I didn't have time yet...) Or maybe we could think of some alternative ideas on how to improve x?
@maximbaz It seems to me a kakscript could achieve anything, so sure. Except for visual full-line selection, but it's debatable how useful it is. However I don't know how many drawbacks that has. It's unclear to me how do different plugins interact with each other when all of them are trying to remap some basic commands. Something tells me that this will lead to problems like: alexherbo2/auto-pairs.kak#9, but maybe I'm wrong.
About other ideas to solve the problem: There is a fundamental problem that empty line is counted as selected line. Something's got to give and introduce that distinction somehow.
For a moment I was toying with the idea in which kak embraces | cursor shape available in many terminals, so that a selection does not have to always select at least one character. This way both | cursor support could be introduced in kakoune, and doing j would not select anything on the empty line it enters. This way x problem is gone, because there is a difference between empty line, and fully-selected line. But that's probably even more radical change, and frankly I don't have time to even iterate over it.
If I understand you correctly, having | cursor shape in normal mode would be weird, you've got to see which character is under cursor when e.g. you press r (also there's a fundamental issue of using native terminal cursors, see #2194 for my attempt to get people excited about it).
which character is under cursor when e.g. you press r
If I did a h, l, I will have one character selection and I can do r. Or one can do ;r to change no-selection | to one-character selection. What's the problem?
I could totally see | working just fine. One problem with it: it is a drastic change and a lot of work.
If I had time that I totally have not, I would toy with making a code editor from scratch, taking all the good ideas from kakoune and pushing them forward in a different philosophical direction: VimGolf is quite pointlessly counting number of keypressed which doesn't matter a bit in real life. What matter is fast and predictable editing. If I can do some operation with 5 keypressed, that I can execute quickly without thinking, than it's better than doing in 3 where I have to pause and think about it.
Took a bit of time to read this discussion. I am surprised that the empty line behaviour seems to be problematic, I guess I am used to it, but making that behaviour more obvious was one of the motivation for highlightling when the cursor is on the end-of-line character.
I do not really get how the interactive behaviour is surprising, you can see that the whole line is selected because the cursor has a different color, indicating that there is only an end-of-line character on that line.
This behaviour is not specific to empty lines either, any line that is already fully selected will not be selected by a x, and <a-x> is here, mostly for the scripting case, where we cannot see easily if the full line is selected or not.
It seems what is really wanted is a line-wise mode, which I believe should be implementable relatively easily (Using something like on-key %{exec '%val{key}<a-x>'}). It could also be built-in, but I am not sure adding this complexity and blessing submodes in normal mode is something I am comfortable with.
Regarding the latest discussion and the | selection, that would be a major change in Kakoune internals. Kakoune selections are always "onto" some characters, not in-between them, this is a core design decision that avoids many special cases (we do not have to distinguish empty selections from non-empty ones, think about how backspace works in other editors).
I do not really get how the interactive behaviour is surprising, you can see that the whole line is selected because the cursor has a different color, indicating that there is only an end-of-line character on that line.
Let me try to demonstrate this with a gif. Notice that you have to pay very close attention to a shade of white color under cursor to understand whether I need to press xd or d to achieve what I want. What @dpc is trying to achieve is a consistent behavior of xd, which in this example will always delete a line. And before you ask, yes I know about workarounds such as making whitespaces visible, it's just an example.
@mawww Visual feedback is of no help at all, because the problem is not that this behavior is invisible. The problem is that one has to pay attention to it.
I want to fly in my the editor, just banging super-fast on the keys, without paying much attention to the actual buffer content. 99% of the time I don't "play VimGolf," but just do very quick mechanical actions. Move this 3 line part? XXXd. An action that behaves differently 10% of the time, is just killing it, and the fact that if I slow down, I can see why, is no help at all.
Just one more thought to add
and
<a-x>is here, mostly for the scripting case, where we cannot see easily if the full line is selected or not.
It sounds like while people got used to x being inconsistent in what it selects, a workaround had to be found for scripts, and this is how <a-x> was born. From asking around on IRC I found that some people learned to pretend to be scripts and press <a-x>XXX because they want consistency and muscle memory (there were some variations of this approach, e.g. mapping x to <a-X> and using xJJJ).
If we manage to make x consistent, not only we will be able to free up <a-x> shortcut which will become obsolete, we will also allow people to have simpler shortcuts like XXX in their muscle memory.
@maximbaz Seems part of the problem there is your colorscheme not making cursor on eol different enough from cursor not on eol.
@dpc I am not sure I get your point, when I delete lines, I dont do that without paying attention, I decide I want to delete that line, and usually the content of the line is pretty important to make that decision.
Thats not to say we cannot improve on x's behaviour, one possibility that comes to mind is to just bite the bullet and make x behave as <a-x>. Just use J/K and get full lines with x. It will break muscle memory, but would improve consistency. (Not sure I like this idea, but its a possible direction).
@dpc I might add as well that XXXd selects one line too many, you could have seen that immediately after the first X, and you would have the selections you wanted after the second X.
@maximbaz In my view x is not really inconsistent, its logic is relatively simple "select fully the line on which the cursor lies, if that line is already fully selected, select the next one", at least it does not seems more complex than "select fully the line on which the cursor lies, if the last command was already x select the next one" (and IMHO is more predictible because you can see if the line is selected, instead of having to remember if the last key you typed was x)
I decide I want to delete that line, and usually the content of the line is pretty important to make that decision.
Maybe I'm from a different world, but I hack and slash my code left and right, with a speed of a machine gun, selecting, deleting, yanking, pasting stuff all the time, jumping between buffers left and right. There's always undo, or even git reset --hard HEAD. I don't meditate at every line.
In my view x is not really inconsistent, its logic is relatively simple "select fully the line on which the cursor lies,
It doesn't matter there's a consistent explanation for it. What matters is if that's what the user naturally expects. Otherwise one could have any arbitrary rule like "selects full line if it's Saturday". Consistent? Consistent! Easy to understand? Yes! Can users keep track if it's Saturday? Of course they can: it's even easier, because days don't change every time you change the line! Does it give a great UX? Not really.
Just had an another out of the box idea.
Maybe there should be a -1 column? Yeah, you heard me right. A column that is left of what everybody consider the first column.
Whaaaaa? you ask?
Here's how it works. Column -1 is magical place where the cursor lands when the \n of the previous line's \n was selected (in which case previous \n is highlighted), or when the line itself is empty (in which case previous \n is not highlighted).
To visualize.
Legend first:
- first column is the
-1one, and is.if empty (just for visualization) Xis cursor.UPPERCASEis selection._is highlighted newline (just for visualization)
Staring position:
.abXd
.
.abcd
After moving with j to a an empty line:
.abcd
X
.abcd
After first X:
.abcd
._
Xabcd
.
after second X:
.abcd
._
.ABCD_
X
Benefits: expected behavior. the additional "state" (empty vs full line selected) is now visible and part of positioning system.
The column does not have be really "wasted". If cursor shapes are available cursor on line -1 could be visualized as | on column 0. If cursor shapes are not available, the cursor could be on whatever is on the left side of column 0. It doesn't hurt anything.
Variations of this idea exist. Column -1 could be used eg. to place the cursor, only if the cursor lands on an empty line, but haven't selected the \n on that line yet. In every case the core idea is : this additional bit of information (empty line vs fully selected one) has to go somewhere. If it can't go into invisible sub-mode state, it has to go into the editing buffer itself, in form of an additional column.
My point is mostly that I dont see how the proposed change is a clear improvement on the current behaviour. In both cases we need to track an additional state ("is the line already fully selected" or "was the last command hitten in this client x), one has the advantage of being visible, the other has the advantage of being something you just did (most of the time). My main concern with the new change is that it seems to break scripting in subtler ways because that state is an additional bit, instead of being derivable from the current selection and buffer state.
(Just saw that you posted a new proposal, I'll go through it when I get time, gotta go now).
My main concern with the new change is that it seems to break scripting in subtler ways because that state is an additional bit, instead of being derivable from the current selection and buffer state.
This state could be tracked per-client/script. I also thought about keeping that state only for interactive input from the terminal. This is especially the route I will take if there will be no consensus on making x work in a way I would be happy with. I'll just keep rebasing my patches, and scripts and plugins will not know that I've implemented any change in a behavior.
@mawww So, as we've talked on IRC - I just went ahead and implemented it in a text editor I hacked together in Rust: https://github.com/dpc/breeze . Obviously toons of stuff is missing there and there are probably many bugs in whatever is implemented, but I did implement x and X in a "out of the box idea" from couple of posts before.
Any progress here? Think alexherbo2/auto-pairs.kak#9 is waiting on this, would love to see resolution but I know this was somewhat contentious.
Edit: Never mind, I was wrong about the dependency. Ignore this.
Late to chime in, but I also wanted to say I love @dpc's suggestion.
Regarding the discussion about "stateful vs stateless" behaviour - think of it this way - either it's implemented in a stateful way which may be less elegant etc, or the user has maintain state in their head ("I'm on an empty line, hold on, I shouldn't be pressing x, I need to press a-x to select it"). The more stateless the end-result is from user's perspective, the easier it is to train the muscle memory (e.g., "xd to delete a line, wherever you are located and whether it's empty or not"), and computers are arguably better at maintaining state than users' heads.
I find it quite hard to do something like C or S or D in vim without doing scripting. Comparing to vim, one needs to do giGlc in kakoune but only S in vim.
Possibly foolish question: why does the current behavior of x exist at all? As I understand it, x has the following purposes:
- When the selection is part of a single line, extend the selection to cover the whole line (unless the cursor was on an empty line, in which case it selects the next line). This is the same as
<a-x>, except without the inconsistency on blank lines. - Select multiple full lines by hitting
Xrepeatedly. For example,XXwill select two lines (unless the cursor was on an empty line, in which case three lines will be selected). This can be accomplished with the same number of keystrokes withJ<a-x>, except without the inconsistency when starting on a blank line. - When a selection contains parts of multiple lines, extend the selection to the end of the last line. This can also be accomplished with
<a-L>. (However this doesn't select the newline, if any.) - When the selection contains parts of multiple lines, change the selection to only the the last line. The same can be done with
;<a-x>. (This does require more keystrokes, but I would guess this is a very rare use case.)
As a new user to Kakoune, I found the distinction between x and <a-x> very confusing, and now I know why. x seems to be redundant, with all of its uses accomplishable in other ways with no more keystrokes (and more consistent behavior on 1. and 2.).
I'm going to be trying out the following mappings for my personal use:
map global normal x <a-x>
map global normal X giGl
map global normal <a-x> ghGl
@greneholt I have actually been thinking about the same thing recently, that we ought to be able to get rid of x altogether (making it behave as <a-x> currently does). I have been experimenting a bit with it and its currently quite painful due to muscle memory, its also weird to do to hold shift+j to select a bunch of lines then have to release shift to hit x.
Still trying, I think Kakoune has too many normal mode commands at the moment so I'd be really happy to remove some redundant ones.
As an observer with limited understanding (which has grown reading this).
I did <s-c> as it's quite prominent in the docs.
I also did <a-s-c> as it was easy to find, which was neat.
I did x which was interesting.
I saw that <s-x> did the downwards selection.
But <a-s-x> didn't do upwards selection, which my brain just expected to work (doing <s-x> in the opposite direction.
I wonder if it is (somewhat) safe to remap x to <a-x>.
BTW <a-x>J does something like linewise selection, but <a-x>K doesn't as the cursor stays on the EOL, where I'd like it to stay at the start of the line.
I realize that I have a broken mental model and it doesn't match up with Kakoune. I don't think Kakoune should come pre-bent to my mental model, but at the moment I don't understand how to safely bend it.
A new experimental branch has been started on the topic: 850c88c
I think this can be closed now :)
I'm waiting for NixOS to bring the latest version, but after reading the latest release notes, I think this one is indeed done.
Correct me if I'm wrong but after using new vanilla version for a while it seems that no new state was actually introduced, so there's no way to differentiate between unselected empty line and selected empty line. That's why x does not advance at all anymore, and people on forums can't make X behave to consistently extend selection by a line.
I guess back to my fork it is for me.
it seems that no new state was actually introduced, so there's no way to differentiate between unselected empty line and selected empty line
technically there is, the state is the "target column" but it's not exposed explicitly
given
abc
def
where the selection is on a.
jjwill move the cursor todjxjwill move the cursor to the EOL character afterdef(selected empty line)