Added search_selection_bounded to search with word boundaries

[mitsuhiko]

This adds a new command search_selection_bounded which works like search_selection but adds \b word boundary markers around. This lets a user emulate the * behavior from vim as such:

[keys.normal]
"*" = ["move_prev_word_start", "move_next_word_end", "search_selection_bounded", "search_next"]

(Before I used shrink_selection here but that does not work as well)

I did not want to touch the behavior of search_selection but I think generally that bounded search is likely what users want. It's quite practical when quickly jumping between a function declaration and uses of it in the same file in many languages.

Refs #1762 which discusses behavior of the * based search.

One other significant difference between how search in Vim and Helix works is that as a * user you are quite used to the search staying highlighted. That however is an otherwise unrelated issue that (see #1733). Beyond this I think the behavior of * can be matched now though for people who want it.

[mitsuhiko]

Small aside: shrink_selection is not ideal here. Preferrable one would be able to use what miw for better behavior, but that requires the current mi/ma dialog to be scriptable. See or #1723 or #4287 for PRs which expose this functionality.

[the-mikedavis]

Yeah, shrink_selection needs there to be tree-sitter support for the language and doesn't work as you might expect within injections. I've seen ["move_prev_word_start", "move_next_word_end"] as a workaround

[mitsuhiko]

I actually tried that, but that also doesn't let you hit the selection on the first character (actually that probably should work, let me try that). Personally I'm now using this in combination with the changes from #4287 and I love it:

[keys.normal]
"*" = ["select_textobject_inner_word", "search_selection_bounded", "search_next"]

//EDIT: you are right that prev/next works pretty well

[mitsuhiko]

I have been thinking about this a bit now and an interesting other option would be to instead of adding this command, to instead have a modify_search_add_bounds function which reads the register and writes the same regex back, adding \b markers on both sides if they haven't been there yet. The reason this could be interesting is that this would also be useful for custom searches if bound to a hot key.

That way one could search for foobar and if it turns out that there are just too many foobar_X one could hit another key to automatically resubmit the search with word boundaries.

[mitsuhiko]

At this point I have a small preference of #4322 over this one here.

[mitsuhiko]

Since #4322 was merged I'm going to close this PR as it is now no longer needed.