Target for non-matching, non-letter delimiters?

[airblade]

Let's say I am editing the text puts object.some_long_method rescue nil.

If the cursor is somewhere in long then ci_ will cut long and leave me in insert mode. Yay!

I'd like something similar where the target is delimited by not-necessarily-matching non-letters, i.e. the character class [^a-zA-Z]. For the sake of argument let's call this "target" x.

With the cursor anywhere in object, cix would cut object because its start is delimited with a space and its end is delimited with a full stop. Similarly with the cursor anywhere in some, cix would cut some; or with the cursor anywhere in method, cix would cut method.

Is there a way to do this with targets.vim?

[wellle]

@airblade: Yes, technically that's certainly possible.

I'm not sure how we want to set it up though. Here's what I came up with:

let g:targets_separator = [
    \ ', . ; : + - = ~ _ * # / | \ & $',
    \ ['x', '[^a-zA-Z]'],
    \ ]

The idea is to extend some of the settings that currently expect a string of space separated items to allow a proper vimscript list having multiple items (while maintaining the current interface). If such an item is a string, it's handles as before. If it's a list of length two, we consider it a key value pair of separator trigger and separator regex.

This is a bit more flexible than a dictionary, especially if we want to use the same idea for pair objects where we might want to have one opening regex and one closing regex, being three fields per pair spec.

Let me know what you think about this approach or if you have another idea of how to set it up.

[airblade]

That sounds like a good approach, though I'm not too familiar with the various settings – I have always used targets.vim as is.

The only other approach I thought of involved tinkering with &iskeyword to make vim's word text-object letters-only. But that changed the behaviour of many other things undesirably, e.g. search, completion, etc, so I ruled it out.

Your idea looks simple and flexible to use, though I have no idea about implementation complexity ;)