Jump to nearest match behind or ahead

[txtyash]

I believe this could be done better than neovim since in neovim it's only possible to jump to the next match only ahead.

If there's this block of text(| represents cursor):

This | cursor [goes] anywhere|

Let the cursor be before [ or farther from ]
Then pressing md[ should:

This cursor |goes anywhere

[the-mikedavis]

You're saying that md[ should jump to the [ to delete when it is contained in the selection?

[txtyash]

@the-mikedavis nothing about the selection. md[ should jump to [ to delete regardless of the selection but only on the current line.

Better than vim, it should check both forward and backwards.

[the-mikedavis]

md is specifically for deleting the given character when it surrounds the selection.

This should be accomplished by searching for an open bracket - /[ (?[ for reverse) - and then deleting - d.

Commands that automatically jump to some character like the current behavior of C-a or C-x break the select-then-act paradigm and the jump behavior should be removed (#3028).

[txtyash]

Honestly, I don't mean to hurt anyone's feelings. The selection behavior is intervening a lot while editing. While editing I am thinking less about editing and more about aiming. Everytime I have to keep planning just the right amount of keystrokes to make a selection and then do the very simple edit that I had to do.

Not sure what kind of consistency the developers are trying to achieve here but why make the user put more work if they just need to C-a, md[, etc. if helix could have the ability to jump to nearest match?

Half, the time I don't even need the selections I make while moving around but when I do, I really have to aim and capture the territory with planning.

The current editing model seems fine though. A few extra keystrokes aren't going to do any damage but if this behavior has to be unnecessarily followed in examples such as above then it is extra work for the user just do to teeny-tiny edits.

Btw, I really liked how things work in multi-cursor mode... That's better than block selection mode for edits. So, not completely against this model but sometimes it is unnecessary

[the-mikedavis]

why make the user put more work ... if helix could have the ability to jump ...?

Working on selections is more predictable because you can see what text the action (increment, decrement, delete, etc.) applies to. Sometimes this costs keypresses but IMO predictability is more important than terse keybinds.

[txtyash]

@the-mikedavis we should have a detailed discussion over keybindings whenever you people have time...

[EpocSquadron]

After having spent a lot of time tearing out my hair making #3344 work with all the edge cases, I'd have to say trying to implement this would lead to a lot of tears in implementation, and likely would produce a whack-a-mole of "do what I want" bugs. I'm firmly in the camp of making things visually explicit being more important. If we wanted things to work blindly, we would just use the vim keymap altogether.

[txtyash]

I understand the concerns of consistency with the selection->action model. The number of keystrokes and speed should also be prioritized. In this case & in general my suggestion would be:

1. We can introduce two modes. A verbose and a non-verbose mode. In the verbose mode users strictly follow the selection->action model. In the non-verbose mode helix will allow users to use keys like C-x, C-a, etc. without having to make selections.
2. We could prioritize the number of keystrokes & let helix jump to the part to be edited.
3. Completely follow the selection->action model and make users select the part to be edited before action.
4. Add a magical new feature that also strictly follows the selection->action model as well as does these actions in lesser keystrokes, since the current keystrokes for surround are already one key extra than vim which is fine but adding more to it would be too much.

I'm aware that helix isn't competing with vim in terms of keystrokes, etc. But optimizations in all areas should be considered. And since it is a modal text editor, the number of keystrokes should be also one of the main focus which I rarely get to see.

BTW, @EpocSquadron This isn't something I should tell but I always wished helix were entirely based on vim's editing model. It's great nonetheless hehe...

These are just my(a users) thoughts. You guys obviously have more experience and your decisions will certainly be the best for helix. Feel free to close.

[the-mikedavis]

Supporting multiple paradigms in the same code-base would be a lot of work and we're not interested in it - it's the same reason we don't support an "evil mode" (vim keybinds) out of the box.

Reducing the number of keystrokes needed for something is fine (for example #3893) but not at the cost of breaking the select-then-act paradigm. The vision doc is explicit about our priorities:

helix/docs/vision.md

Line 19 in 5467c65

* **We aren't playing code golf.** It's more important for the keymap to be consistent and easy to memorize than it is to save a key stroke or two when editing.