Adding Seek Behaviour in Cases of No Action

[noctuid]

This is a feature request for adding seek behaviour kind of as a fallback.

The TextObjectify plugin lets something like vi" work for multiple lines. '[]' represents the cursor. The lines in between the quotes are selected:

"
Some text...[]
Some more text...
"

This already works with textobj-anyblock, but it seems that it comes at the expense of seeking even for quotations. Normally, in the following situation, vi" would seek forward and select the text within the quotes:

Some text.[ ]"Some quoted text."

TextObjectify extends this behaviour to parens, brackets, etc. as well. I think it would be nice if textobj-anyblock would seek forward in cases where it would otherwise do nothing. In the example above, ib just acts on the character the cursor is over (a space). Because textobj-anyblock deals with many text objects, seeking can't be the same as with TextObjectify. For example, vi( will select the text inside the parens but vib will select the text inside the curly braces in the following example:

{curly text[ ](paren text)}

This is to be expected, and a seek should not occur, but I think there can rules put in place that will cause ib and ab to seek under certain conditions where there would not or should not be a conflict with normal behaviour. For example, the first two of these rules would prevent conflict and, in most cases, give the desired result:

1. There are no blocks (),<>,'', etc. surrounding the current cursor position, not just on the current line but multiline. Otherwise, textobj-anyblock should act as normal and act on the innermost block the cursor is within.
2. Unclosed blocks (e.g. an unmatched < at the top of the file) are ignored when determining whether to seek and when seeking. textobj-anyblock already doesn't do anything in a situation where only an unmatched block is present.
3. This is a suggestion and not necessary: Single quotes following a letter (e.g. Sam's in written text or modifiedFunction' in Haskell) are ignored. Currently, textobj-anyblock will act an large sections between single quotations intended to be apostrophes. Now normal vi' will do no such check (which can be annoying), but I think especially with textobj-anyblock where ib can refer to many different blocks, this is a problem. This is a problem even without seeking implemented, for example:

(
Sam's intention was to select the text inside the parens using vib.[]
Sam's keypresses instead selected the text inside the two apostrophes.
)

Only for lisps:
4. Single quotes before letters or an open paren are selectively ignored in lisp files if they are not matched by the end of the line (and maybe in the same paren nesting level). This isn't enough to deal with things though. For example, this is a line from my ~/.emacs: (add-hook 'linum-before-numbering-hook 'my-linum-get-format-string). To deal with this, if the potential closing single quote is preceded by a space, it is not considered as a closing quote. I don't know if this covers all or even most of issues with lisp since I've hardly dealt with it though. It may not even be worth it to bother with this.

Now I think there may be some cases where a seek was desired and a large surrounding block was selected instead. Having options to consider indentation or line range among other things to choose when to seek might be nice, but none of them are necessary to implement a basic seek in the mentioned cases where textobj-anyblock would already take no action.

Also, thank you for the wonderful plugin.