Add command to select arbitrary words (similar to goto_label)

[clo4]

This PR refactors the jump_to_label function to make it reusable for other use cases (now implemented as prompt_for_label), and implements a new command (add_selection_on_word) that allows you to add a new selection on any word, instead of replacing the current selection. It adds gW as a default binding for this.

I'm not happy with the names so bikeshedding is welcome.

[the-mikedavis]

What's the intended use-case for this? Since we select words with the jump labels, it's pretty imprecise to add selections this way. I could see it potentially working as expected within prose like markdown documents but for programming languages I would imagine that the jumps aren't precise enough to form useful selections compared to selecting regions and using s, or using syntax-tree or textobject selections

[pascalkuthe]

Yeah I would rather see this usecase adressed with marks that allows you to append a selection to the mark. Then you could jump around the screen with commands like gw or search, make a new selection (for example using tree sitter commands or just manually using select mode) and then append that selection to the mark.

[clo4]

I would imagine that the jumps aren't precise enough to form useful selections

I'd definitely have thought so too! There's two parts to this that aren't immediately obvious but provide a really nice workflow:

1. You can select in multiple places and then expand those selections e.g. using tree-sitter motions, because you're right that some of the time a word is too fine-grained. I think of these situations as me just wanting to throw a selection over to some part of the document so that I can expand it to where I need it to be.
2. Surprisingly often a word is exactly what I want to operate on. That's what I've found in practice, at least for myself. Can't speak to others. I (may?) have done more mushing data into different formats than an average person, this makes doing that kind of stuff a lot easier.

Editing prose is one use for it for sure. Some examples of other workflows I have in mind (there are many more, just what comes to mind immediately):

• With a word in, say, paragraph 3 selected, gW to select a word in paragraph 5, map<A-)> to swap the paragraphs.
• Changing the case of multiple unrelated tokens (eg. from snake case to camel case)
• Place a selection inside multiple unrelated quotes or parentheses and change the type of surrounding characters in one command. (useful for JS for transforming strings to tagged template strings)
• Transforming some JSON from an API response where you want to select the values of some particular keys.
• Select just two of the N arguments in a function and rotate their order. Even for something like python kwargs, you can place a cursor on the arguments and use tree-sitter motions to select the whole argument.

For prior art, most GUI editors (and as it turns out, some TUI editors too) support doing this by holding a modifier and double clicking. This is functionally a fully text-based equivalent to that, and I think it's also more efficient as a result.

Yeah I would rather see this usecase adressed with marks that allows you to append a selection to the mark [...]

Marks solve a lot of problems and it would be good to have them implemented, but I don't think that they're a particularly elegant solution to selecting arbitrary text. They introduce additional steps and overhead that needs to be considered for what should be a conceptually simple operation. And secondarily, would that be any better than just recording a macro, using gw, then replaying it?

---

Anecdotally, just as a normal user of this editor, when I saw that goto_word and extend_word were implemented, I was actually surprised to see that this was missing because (subjectively) it feels like quite a natural feature and complement to those commands.

I hope this hasn't come off as rude or negative! My opinion is that this is a better solution that's also more intuitive, but I understand if you don't feel that way about it. Even if we don't come to a mutual understanding about what makes a simpler / faster / more ergonomic workflow, I think the refactor may still be of value if this type of selection interface is going to be reused in the future by other commands. One that comes to mind would be displaying labels on selections and typing a label to remove the selection, as opposed to the current workflow of cycling through them all until you get to the right one then using A-,.

As a final note, I trust your judgements on this, if you say marks or macros are the way to go then I've got faith in you as maintainers. I'll keep my fork with this up-to-date though, because this solves a real pain point for me :)