delete_word_backward and delete_word_forward behave unexpectedly in some cases

[ghost]

Summary

The delete_word_backward and delete_word_forward behave unexpectedly in some cases.

My impression is that there are two things going on here: my expectation that \n counts as a word (which might not be a bug), and unexpected behavior when there's nothing under the cursor (which probably is).

Reproduction Steps

1. Bind delete_word_backward and delete_word_forward to a key in insert mode.
2. Use the keybinds as in the following examples.

delete_word_forward

With the cursor | on line 1:

1 |
2
3 type some words

Pressing the keybind will remove type_, some_, and then words, leaving the cursor on line 1 and all the newlines intact. I'd expect line 1 (the \n) to be deleted, then line 2 (another \n), then type (and maybe the following space?), etc.

delete_word_backward

With the cursor on line 3:

1 type some words
2
3 |

Pressing the keybind will delete words, some_, and then type_. As in the forward case, this will leave the newlines untouched. I'd expect the newlines between the cursor and the words to be deleted one at a time first.

..

With the cursor at the end of line 1 and no trailing newline:

1 type some words.|

Nothing happens.

..

With the cursor on line 1 and no trailing newline:

1 type some words|

Pressing the keybind will give:

1 type some s|

And then the keybind no longer does anything until I reposition the cursor.

..

There's another weird case where, upon using the keybinding, I end up with two spaces between the cursor and whatever words are left, but I can't seem to reproduce it.

Helix log

No response

Platform

Linux (5.18.2-arch1-1)

Terminal Emulator

foot 1.12.1

Helix Version

helix 22.05

[SoraTenshi]

This bug also affect move_next_word_start and move_next_word_end as well as the prev versions.

seems to be a problem with "what counts as word"

[PabloMansanet]

Hey! I'm the one who wrote the unit tests and word navigation stuff :) after having a chat about it with @s0LA1337 , we concluded a couple things:

• Delete previous word is certainly bugged, as it seems to leave one character untouched when called after the word boundary. I'll be looking into why that is.
• Word movement is not bugged, it's just implementing kakoune-style word navigation as opposed to vim. Newlines on Kakoune are not handled as words, and this behaviour is consistent with that. We can have a conversation about whether that's desirable, though.

[ghost]

My expectations regarding delete_word_* and newlines mostly come from the Control + Backspace and Control + Delete shortcuts from VS Code, each of which deletes words or empty lines one at a time. I do not know if this behavior would be a good fit for Helix.

If the one-line-at-a-time approach is not a good fit, I would still expect these bindings to delete everything between the cursor and the next word. In the first example in the OP, this would be \n\ntype; in the second, words\n\n. The current behavior (as reported, anyway), where the cursor stays on one line while a word is deleted from some other, distant line, definitely feels awkward or broken.

[AceofSpades5757]

I think the movements are correct. This is a different style of movement, as seen in Kakoune. I would expect similar movements to select/delete the newlines as well, but I'm still getting used to this new way of thinking compared to similar editors like Vim.

[adsick]

@AceofSpades5757 yea, just "different style of movement"(tm) which nobody understands.

[adsick]

I personally don't get Ctrl+left/right navigation in insert mode, it looks wrong to everything I've seen during years of experience.

[AceofSpades5757]

@adsick I try notepad, this text area I'm typing in now, and Helix. They all have almost identical ctrl+left/right navigation ¯\_(ツ)_/¯.

I'm still a fan of this new style of movement. I'm excited to see what comes from it.

[archseer]

Fixed by #4392