Enhancement: Jump-to and select from multiple matching text objects on a line (e.g. multiple quotes)

[hadynz]

Hi 👋 — thanks for the fantastic plugin!

I’m wondering if it would be possible (or desirable) to support an integration point that allows users to jump to and select among multiple matching text objects on the same line — for example:

• A line with multiple quoted strings: 'first' 'second' 'third'
• Triggering a command like ci' would normally operate on the first one, but there's often a need to pick one of the others
• It would be amazing if a key like gci' or similar could highlight all inside_single_quotes text objects on the line and let the user choose one using a plugin like flash.nvim, hop.nvim, or leap.nvim

Potential workflow:

1. User invokes a motion or operator tied to a specific text object (e.g. inside_single_quotes)
2. All matching text objects are visually highlighted via jump labels
3. User picks one, and the text object is selected for use with an operator like c, d, etc.

I imagine this would require exposing a hook or API that returns all ranges matching a particular text object so a jump plugin can render targets and feed back the selected one.

Curious if you’ve thought about this, or if you'd consider supporting something like this — happy to help prototype!

Thanks again 🙌

[chrisgrieser]

Thank you for the kind words

---

I imagine this would require exposing a hook or API that returns all ranges matching a particular text object so a jump plugin can render targets and feed back the selected one.

This would in theory be possible. Are there in turn even any jump plugins that have an API to take a list of ranges as possible jump targets?

---

Regarding the idea itself: I actually tried out it remote text objects like that a while ago (can't remember the name, but there are some plugins that do sth like this for the builtin vim text objects). However, the workflow did not really click with me:

you essentially have to learn a second set of keybindings for the remote version of every object you use. I found that using a jump plugin to go to a text object, then use the text object as normal, and then jumping back via <C-o> gives you pretty much the same result without the need of learning new keybindings.

Thus I am somewhat unsure how much value the workflow you outlined would actually have in practice.

[hadynz]

This would in theory be possible. Are there in turn even any jump plugins that have an API to take a list of ranges as possible jump targets?

Not that I know off. Had a quick look at leap and hop's lua api and nothing immediately jumped to me.

Regarding the idea itself: I actually tried out it remote text objects like that a while ago (can't remember the name, but there are some plugins that do sth like this for the builtin vim text objects). However, the workflow did not really click with me:

I saw that flash does that, and agree with you that remote text objects is a differetn workflow.

What I am suggesting fits in the current workflow. For example, using hop, I often will use f with hop targets to choose which target to jump to quickly.

I would love to have something similar that is triggered with a motion/operator+text object

const arr = ["hello", "there"];
^

On typing ci", the candidate text object targets are replaced with a and b

const arr = [ahelloa, bthereb];
             ^     ^  ^     ^        

-- choosing `a`
const arr = ["", "there"];
             ^

[chrisgrieser]

I saw that flash does that, and agree with you that remote text objects is a differetn workflow.
What I am suggesting fits in the current workflow. For example, using hop, I often will use f with hop targets to choose which target to jump to quickly.

Tbh, it does not look that different to me. In your example, I could use the jump plugin to jump to either "hello" or "there", and then use ci" (which, btw, is offered by vim and not this plugin.)

It's the same number of keystrokes as the workflow you describe, more visual cues (all the jump locations vs. only a few objects), but does not require learning new keybindings.

So from what I can tell, the feature you suggest is only minor improvement imo (and I personally wouldn't even use it, since a few more visuals cues is preferable to me than learning a full new set of keybindings). And for that minor improvement, I'd need to expose an extra API, maintain that API, and also hope one of the jump plugins (two of which are abandoned afaik) implements a corresponding API before that improvement is even realizable. Given this prospect, I am currently not inclined to put in the work for that, sorry.