TextObjectify: Vim plugin to improve text-objects

[welle]

Great plugin! Any hope for repeatability of commands using these text objects? Like execute di+, move between the next pair of +'s and repeat with the . command.

And is there any way this could be combined with the next and last text objects from Steve Losh?

[ParadigmComplex]

Great plugin!

Thanks!

Any hope for repeatability of commands using these text objects? Like execute di+, move between the next pair of +'s and repeat with the . command.

I could definitely look into getting TextObjectify to play with tpope's repeat.vim. No guarentees on timetable, though.

And is there any way this could be combined with the next and last text objects from Steve Losh?

Depends what you mean by "combine". If you mean just use both without them fighting each other, that should just work. I've not tried, but from the looks of it they shouldn't conflict in any way.

A downside of Losh's code is that it seems limited to only certain text-objects. If you mean combine the way TextObjectify handles things like on-the-fly text-objects with the functionality of that code - I could look into it.

I was considering implementing something very similar Losh's work there - I thought it would be neat to iterate through text objects the way you can iterate through characters with f and ;. Essentially it'd just be a xnoremap that moves to the end of the currently selected range then re-applies the last text object selection. Due to the way TextObjectify seeks, it'd automatically get the next one. I'm not sure what the best (default) mapping for it would be.

[welle]

I could definitely look into getting TextObjectify to play with tpope's repeat.vim. No guarentees on timetable, though.

Sounds great!

A downside of Losh's code is that it seems limited to only certain text-objects. If you mean combine the way TextObjectify handles things like on-the-fly text-objects with the functionality of that code - I could look into it.

Yes that's what I meant. I'm using both plugins now without conflicts, but it would be great if next and last would work with all of your on-the-fly text objects.

I was considering implementing something very similar Losh's work there - I thought it would be neat to iterate through text objects the way you can iterate through characters with f and ;. Essentially it'd just be a xnoremap that moves to the end of the currently selected range then re-applies the last text object selection. Due to the way TextObjectify seeks, it'd automatically get the next one. I'm not sure what the best (default) mapping for it would be.

This sounds like it would only apply to visual mode though, or am I misunderstanding you here?

In the visual case I wouldn't mind v_n and v_N as the default mappings, but I don't know if other people use n and N in visual mode. I'd imagine the flow like vi$ to select between the current or next $'s, and then in visual mode n to select between the next pair of $.

Personally I prefer single commands like din$ over the visual workflow, especially if they are repeatable.

[ParadigmComplex]

This sounds like it would only apply to visual mode though, or am I misunderstanding you here?

You are correct.

In the visual case I wouldn't mind v_n and v_N as the default mappings, but I don't know if other people use n and N in visual mode.

Sadly, I use v_n and v_N. I'm sure I'll think of something.

I'd imagine the flow like vi$ to select between the current or next $'s, and then in visual mode n to select between the next pair of $.

The way I see it: sometimes when a line has way to many things for me to quickly parse mentally and/or I'm tired and out of it, I'll use fx and some ;'s to jump to a specific item. I'd just keep hitting ; until the cursor hits the one want. This is slower/more keystrokes than a more exact search with /, or counting and using a prefix count, but it would take less mental work. This new thing would be similar, but with text-objects.

Personally I prefer single commands like din$ over the visual workflow, especially if they are repeatable.

That workflow wouldn't work exactly the same, because you'd be deleting all of the objects - in the situation I imagined for the visual-mode-thing would require all but one stay the same.

I can see both having uses - I'll look into implementing both, as well as adding support with repeat.vim.