rhysd / vim-textobj-anyblock Goto Github PK

View Code? Open in Web Editor NEW

81.0 3.0 4.0 25 KB

A text object for any of '', "", (), {}, [] and <>.

Ruby 24.24% Vim Script 75.76%

vim-plugin text-object

vim-textobj-anyblock's Introduction

One Text Object for Quotes, Parentheses and Braces

This plugin provides text object mappings ib and ab.

ib is a union of i(, i{, i[, i', i" and i<.
ab is a union of a(, a{, a[, a', a" and a<.

ib and ab match any of the text objects. If multiple text objects are matched, it selects one covering the most narrow region. For example, when the current line is ['abc', 'def'] and the cursor is at e, vib selects def.

This plugin depends on vim-textobj-user. Please install it in advance.

If you want to change the blocks which ib and ab match, define g:textobj#anyblock#blocks. For example, if you install vim-textobj-between and want to match `...`, set [ '(', '{', '[', '"', "'", '<' , 'f`'] to it.

If you want to define buffer local blocks, set them to b:textobj_anyblock_buffer_local_blocks as list of string on FileType autocmd event.

License

Distributed under MIT License.

Copyright (c) 2013 rhysd

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
THE USE OR OTHER DEALINGS IN THE SOFTWARE.

vim-textobj-anyblock's People

Contributors

Stargazers

Watchers

Forkers

kevin4fly chun-yang ddrscott infokiller

vim-textobj-anyblock's Issues

Request: Select multiple blocks. Parent blocks.

Can I do something so that when the key combination is pressed, the parent blocks are selected?

Mouse pointer -> *

                                              *
<link rel="stylesheet" href="{% static 'css/styles.css' %}" />

selected text:
css/styles.css

If you click again, the text you have selected would be:
% static 'css/styles.css' %

If you press again, then:
{% static 'css/styles.css' %}

The example is not very suitable, but if there were a lot of spaces or lines it would be very useful.

Two signs were defined as one

Mouse cursor -> *

       *
{{ variable }}

Press vab, selected text:
{ variable }

Can I make it so that when I press vab, everything is selecting, including both curly braces?:
{{ variable }}

Inner block doesn't work if i is remapped in visual mode

Hey,

I have weird vim mappings in which I remap the movement keys hjkl to ijkl, so that the geometry more closely matches that of the keyboard arrows.
I noticed that with my mappings the inner block mappings don't work. I tried to debug a little with my very limited vimscript skills, and it seems that the function get_region doesn't work with my mappings. To reproduce, run the following vim command (before or after the plugin) and try the plugin inner block command: xmap i k

keep jumplist

The operator mode mappings, for example after yq if omap q <Plug>(textobj-anyblock-i), add a mark to the jump list. This seems rather unwanted than useful to me.

Checking the source code, I didn't see where the marking enters. Anyone else?

`vib` doesn't work when at `)`

vib doesn't work when cursor is at ). vab works.

bug: ib and ab behave the same when there's a single character inside

If the cursor is on b in ['b']

dib will delete the quotation as well, behaving the same way as dab.

block with two letters

Dear rhysd,

Thank you for this handy plugin that I use almost exclusively now for nested text objects. There are some quirks but that's to be expected given its universality.

For example, here anyblock gets confused inside blocks of two letters. For example, if * = cursor position and

(i*n)

then hitting cq with omap q <Plug>(textobj-anyblock-i) gives

(i*)
```.
Can you confirm that?

ib doesn't work when i is mapped

this line should use normal! command to make sure any commands in a:textobj are not subject to user defined mapping in normal mode.

currently if I map the i key to something else in normal mode, then keepjumps execute 'silent' 'normal!' a:textobj would not select the correct text region. can you fix it real quick? thanks.

Adding Seek Behaviour in Cases of No Action

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:

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.
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.
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.

Do nothing if not found

Currently, if no block symbols was found at all, char under cursor will be deleted.
It's unwanted behaviour, as it contradicts expectations.
Better is to keep text unchanged -- as expected blocks non-existent.