helix icon indicating copy to clipboard operation
helix copied to clipboard

Separate 'brace action' and 'match selection' functionality

Open asvln opened this issue 2 years ago • 3 comments

The idea of 'selection first' makes a lot of sense to me compared to vim's 'action first'. However, I do not know if the keymap currently adheres to that philosophy the best that it could.

I realized I was using miw so much that I am now capable of just mashing the keyboard with my hands to hit the key sequence. But... I feel really stupid doing this. It makes selecting anything stressful and is very unintuitive, especially when selecting the word under the cursor is my most common selection tactic.

I then realized that the current m mapping really does two separate things...

  1. Working with matched braces
  2. Selecting textobjects

In my opinion, these functionalities should NOT be on the same key/related in keymapping at all.

When (1): After pressing m, I am then making an action. This action has a variable number of additional keypresses to appropriately complete the action. Additionally, each action operates differently in the context of what is selected.

This api is complex and at the end, my current selection is NOT changed at all.

When (2): After pressing m, I am then choosing 'inner' or 'around'. Then I am just selecting the textobject I want with my next keypress (the selection always only requires 2 keypresses after pressing m).

This api is very straight-forward and at the end, my selection IS changed.

If I have an editor that is based on 'selection first', I need to be able to select a textobject within 2 keypresses, otherwise I find it inefficient and repetitive, and that takes away the fun of it all.

Hypothetical Solution

  • Remove all brace actions from m (lets say we nest it under the space mapping to get it out of the way)
  • mi = m
  • ma = M

This solves the issue of 3 keypresses for a very commonly used approach to selection and drastically simplifies how (at least I) understand the editor as a whole.

If this was how m worked when I first started using helix, I would be way more proficient at working with selections and multiple cursors than I am now.

Having direct m access to select a textobject makes the whole approach seem as simple, quick, and intuitive as any vim 'action first' motion.

asvln avatar Sep 15 '22 18:09 asvln

I don't have a strong opinion about the proposal, but I do use miw very frequently as well.

I'd be interested in trying this, is it possible to get this behavior just by remapping keys in config.toml?

CptPotato avatar Sep 16 '22 06:09 CptPotato

I'd be interested in trying this, is it possible to get this behavior just by remapping keys in config.toml?

Yep

"m" = "select_textobject_inner"
"M" = "select_textobject_around"

Omnikar avatar Sep 16 '22 10:09 Omnikar

I'm glad I'm not the only one who thought the existing m functionality felt a bit incongruent with the rest of helix commands and I like @Omnikar's suggesting. Going to try this out

sdemura avatar Sep 16 '22 13:09 sdemura