Modify matching behavior when it fails to find the matching character

[tapyu]

I frequently find myself in the following situation:

|esc = ["collapse_selection", "keep_primary_selection"]

where | denotes the cursor position. I want to match in next inner brackets content, that is, "collapse_selection", "keep_primary_selection". I am not a prohelix user, but AFAIK you need to run f[ and mi[ in order to select it, which is not that effective.

I propose to extend the match mode functionalities to cover this situation:

1. The bind should be mf + any character + one of the match mode binding.
2. The command should apply find_next command to this next character.
3. Run match_brackets, surround_add,surround_delete, select_textobject_around, select_textobject_inner, surround_replace depending whether m, s, d, a, i, or r has been selected.
4. Another bind mF must be considered to search for a matching before the current cursor.

I tried to create a keybind in the config file for this case, but I failed. Moreover, I do think that this situation is recurrent, so other users might also get this functionality out of the box.

Finally, in my previous example, mi[ does nothing, which is pretty stupid. I propose that, once the matching fails to find a pair, it must fallback to my proposed keybind mf[i (or mF[i) in order to find the next (or previous) matching.

If you find mf[i or mF[i too complicated for a single command, I at least propose to modify the behavior of the matching mode when it fails to find matching inner/around/whatever character. To do anything is better than to do nothing.

[tapyu]

Just to let you know, my trial to create a binding for this was

m = { f = { i = ["find_next_char", "select_textobject_inner"] } }

[thomasschafer]

I would also be in favour of adding something like this, similar to the around_next and inside_next commands in the nvim plugin mini.ai, which in the example you shared above would select the contents of the array with vin[.

I'm going to have a crack at implementing this myself.

[thomasschafer]

3. Run match_brackets, surround_add,surround_delete, select_textobject_around, select_textobject_inner, depending whether m, s, d, a, or i has been selected.

I'm confused by this - how would surround_add and surround_delete work? I don't see how it would make sense to run a command like mfi( - where would that add the (?

[thomasschafer]

Apologies, mfi( was a typo, I meant to write mfs(, but you answered that anyway! That all makes sense to me.

My only other question would be whether f and F would be the right keys to use, or whether something like n and p (meaning "next" and "previous") would be better, with my slightly tenous arguments being

• mini.ai (which is built in to the popular LazyVim) uses n already, and users might already be used to that
• typing F requires two keys presses (shift + f) compared to just one for p
• semantically I think "match next inner <object>" makes more sense than "match find inner <object>"

There is one major downside to using n instead of f, however, which is that typing mn quickly is hard because most people would use their right index for both keys. However, this would no longer be a problem if it was decided that the ordering should be min<object> rather than mni<object> (and similarly for other commands), and from a quick dig around I think the implementation would be more straightforward with the former option.

[tapyu]

My only other question would be whether f and F would be the right keys to use, or whether something like n and p (meaning "next" and "previous") would be better, with my slightly tenous arguments being

That is open to discussion, indeed. My idea was to leverage the f and F behavior to go afterwards and backwards to create the mf and mF keybindings with similar behavior.

typing F requires two keys presses (shift + f) compared to just one for p

Agreed.

There is one major downside to using n instead of f, however, which is that typing mn quickly is hard because most people would use their right index for both keys.

I have no idea what "right index" is, so I couldn't understand what the problem with mni<object> is. It seems great to me.

[thomasschafer]

I have no idea what "right index" is, so I couldn't understand what the problem with mni<object> is. It seems great to me.

Ah, I mean right index finger - typing with the "correct" fingers on a qwerty keyboard leads to the right index finger being used for both m and n, although I appreciate that some people use non-qwerty layouts, or just use different fingers

[tapyu]

Ah, I am sorry for my stupidity. I got it now. However, I wouldn't assume that everyone who is on a qwerty keyboard will use the right index twice to type m and n. I see myself using the middle and index finger for that, and I also use a qwerty keyboard.

[tapyu]

A very important aspect about helix. In this situation

|esc = ["collapse_selection", "keep_primary_selection"]

pressing mi[ does nothing. This is stupid. A waste of keys. When a user runs a command, they expect something: doing something is better than doing nothing. Therefore, I propose helix to fallback to mfi[ if mi[ matches nothing.

It is not only effective but also reasonable, if the user is trying to match something and hx couldn't resolve this matching at the current position, the most reasonable solution is to try to find the next matching. Doing nothing is not a reasonable solution, at all.

[thomasschafer]

Created an initial PR implementing finding in next character pair - I'll add to it if we can get an agreement on the approach and implementation

[thomasschafer]

Linking this which discusses essentially the same idea but with different keys used