document w b e also select

[mankinskin]

In the documentation w and b are said to "move to next/previous word start" but they also seem to select the text the cursor jumps over. Is this on purpose? I find it rather distracting and don't see when this would be useful right now. I use w and b mainly for in-line movement and when I want to select something, I would enter select mode at the start of the selection and then move to the end of the selection.

[Omnikar]

This is indeed intentional, and is used for things such as wd, which deletes a word forward. This would correspond to dw in Vim.

[mankinskin]

Hm.. is there some command to only move the cursor word wise?

In any case this should probably be documented.

[Omnikar]

Hm.. is there some command to only move the cursor word wise?

Can you elaborate?

[mankinskin]

In vim, w and b are used to move the cursor to the beginning of the next/previous word, respectively. And I use this command quite a lot. I think this is a very important command in general.

For selecting text there could always be a selection mode, where any movement command extends the selection. This is how vim does it and I always found it very comfortable. Because you don't select text that often. Usually when you select something it is to copy, delete or replace a block of text, but most of the time you are probably just navigating the file or writing in insert mode.

[Omnikar]

Because you don't select text that often.

This is not the case with Helix. In Helix, in order to manipulate some text, you need to select it first, e.g. the example I mentioned before: pressing w to select a word forward, and d to delete the selection. Making motions not select the text they traverse by default would unnecessarily cause this simple operation to require three keypresses (vwd).

[mankinskin]

Yes, this is what I do in vim right now. Maybe I just have to get used to it, but my problem with this right now is that it creates a visual selection when I just want to move the cursor, which is very distracting at the moment.
Maybe an option would be to have invisible selections? So that commands on selections can use the previous block the cursor moved over, without it being highlighted? This would solve both issues, but I don't know if this would conflict with anything.

[Omnikar]

If you really want invisible selections (which I wouldn't recommend), you can edit the theme file of the theme you're using. Specifically the ui.selection field. Alternatively, you could edit the selection colour so that you can still see it, but it is less distracting.

[mankinskin]

Well no, I still want to see selections I make in selection mode. It is just that I don't want to see a selection when I am just moving the cursor, obviously. When I want to select something, I am fine with pressing an extra key. It is better to have shorter commands, but not at the cost of having distracting visual feedback that has nothing to do with my task. If a command like wd is supposed to work, then I would prefer the selection to be "behind the scenes" in this case. But this probably makes d behave unexpectedly when you used w or b before.. I guess I will play around with how it is now for a bit and see if I find it useful.

[cessen]

I agree it would be nice to also have word-wise cursor movements commands, that don't select anything. I find myself avoiding using w and friends for navigation simply because it's visually distracting.

This is indeed intentional, and is used for things such as wd, which deletes a word forward.

Honestly, I don't find myself doing that very much either. The resulting selection starts from where the cursor was, so unless I happen to already have my cursor perfectly placed (which usually isn't the case), the selection only ends up selecting part of the word. For me, a "select the word currently under the cursor" command would be far more useful, so no matter where the cursor is within the word, the entire word gets selected.

I don't mean that the existing commands should be removed, by the way. Just that I understand where @mankinskin is coming from, and would like to also have commands that address those workflows.

[archseer]

I would say this is primarily a documentation issue, this behavior is expected and matches kakoune. I also didn't like this behavior initially and had w/b/e move without selecting for a few months, but after experimenting a bit I think it's much more ergonomic: If you want to collapse the cursor you can always press ;, but this way you can wd a word without having to enter v mode. I don't think this should ever be a new default but maybe users could map w; to w.

It's not any more visually distracting than seeing the cursor move, it just takes some time getting used to: there's no such thing as a cursor vs a selection, a cursor is simply a single character selection.

[mankinskin]

Remapping w to w; would solve this for me. I am just much more used to vim. Generally I think vim did most things right and I think it can be a good starting point for the UX of a new modal editor. But I can also see that it wasn't perfect and probably it is healthy to try some new things.

[pickfire]

From what I recall I almost never had the need to press ; even though I use w quite often.

[mankinskin]

@pickfire yeah, I think it is just not the way it is meant to be used. I am just used to vim, where selections work a bit differently. But I think I can get used to this. I am just missing a few other features at the moment, but that is expected. The base of the editor seems solid, it looks good and I think with a few more extensions to the command language this can become a great next-gen modal editor. I am definitely looking forward to it. I will also see if there are things I can help out with.

[cessen]

I don't think this should ever be a new default but maybe users could map w; to w.

That sounds good to me!

[Ryneqq]

Hey, i am trying out helix and i think i am in love 😄 but actually for me this was also the issue. First thing i did is map my w to w; and esc to ;, (i would love esc to do that by default though). After a while playing i came to conclusion that the best way to approach word selection on movement would be to configure TTL for it

• None for indefinite selection on movement (as it is now)
• 0 for no selection at all
• n ms ttl - which will enable consecutive changes but not distracting selection

It could be configurable by each movement separately.

Btw, w, b, e triggers selection but gs gl gh does not which seems a bit odd to me.