Visual selection issues.

[yashamon]

Vistual selection is currently problematic. For example:

foo bar epsilon delta

cursor on foo. I want to select bar epsilon. Move by w, foo is is selected, go to Visual mode, foo that stays selected. This is almost never what the user intends. If I wanted my visual selection to start with foo I would have used visual selection right away.

So after moving to bar, I have to remove the selection of foo first. And you can't even escape, you must move the cursor around to remove selection.

This issue can be fixed by complicated remapping, which totally defeats the idea of helix to be simpler than neovim. In neovim this already behaves correctly because the movement w is itself modal. In other words as stated by many users, out of the box neovim actually requires less keystrokes in normal use scenarios and is more intuitive to boot.

A simple fix in helix would be to force V to clear all previous selections by default maybe adding another command to enter visual mode and keep previous selection.

Another issue is so bizarre it might be a bug. Example:

foo bar epsilon delta

cursor on bar V/delta does not select until delta, it just jumps to delta. How could this possibly be intended?

[kirawi]

To address the first point:

• This is actually a misunderstanding/misrepresentation of what v actually is. There are technically only two true modes in Helix: normal and insert. v is actually closer to being just a grouping of mappings to commands that extend the current selection. (Just to be clear, select mode is indeed implemented an individual mode in the codebase, but it's used to tell commands to extend the current selection AFAICT) You could rebind v to ["collapse_selection", "select_mode"] to get what you want. It's not complicated, just do :config-open and paste:

[keys.normal]
v = ["collapse_selection", "select_mode"]

• You can collapse the selection via ;
• As per the project goals, consistency is more important than shorter keystrokes.

To address the second point:

• It is intended behavior and how Helix has always worked. I believe this behavior is derived from Kakoune.

[yashamon]

how do you achieve the intended selection in example one? In example two, intended why? It is unintuitive, it vastly reduces productivity.

[kirawi]

For the first example, the binding should do what you wanted without anything else. Just do vw. What I would personally have done instead of a binding is w until bar is selected, and then vw to add episilon

For the second, see #5668 (comment)

[yashamon]

I don't think your non rebind solution is tenable, for suppose we instead have:
foo bar epsilon delta
cursor is on bar you want to visually select foo bar epsilon. If I b then vww this does not select foo bar epsilon since b will select foo and vw will unselect it. With rebind it presumably works.

So it appears to me that the default selection mechanics are just broken.

[kirawi]

foo [bar] epsilon delta
e
foo [bar epsilon] delta
A-; b
[foo bar epsilon] delta

I'd suggest trying to work with and learn the existing selection model for a longer period of time before calling it broken. If you still find something that bothers you, then it'll be a lot more helpful to understand what it is that makes you feel that way.

[yashamon]

I don't think you understand, I am not saying it is impossible to make the selection, after all you can also do V followed by trimming the ends. I am saying it is not consistent! I can keep modifying the example forcing you to keep modifying the approach. That is absurd. In neovim the same trivial algorithm works for any selection.

…

On Tue, Jun 25, 2024 at 8:13 PM Kirawi ***@***.***> wrote: Okay I misread. foo [bar] epsilon delta e foo [bar epsilon] delta A-; b [foo bar epsilon] delta — Reply to this email directly, view it on GitHub <#10683 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQGIZS4RR2BHI6SMFNTYCTZJIBSNAVCNFSM6AAAAABJ2YQG2WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNZWG44DK> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kirawi]

I'm not sure I can agree with you that it is inconsistent. However, Helix follows Kakoune's editing model rather than Vim's, so this is expected behavior. See also mawww/kakoune#2578 (comment)