wellle / targets.vim Goto Github PK

Would you accept a patch that adds the old cursor position to the jumplist if the object is on the same line, but some configurable number of columns away from the cursor? E.g:

int some_int = x + y + this_is_a_long_function_name_that_spans_lots_of_columns(x, y);

If the cursor is on the s in some, and you do ci(, you may want to hop right back to where you were. Personally I run into this situation frequently enough that I think this would be useful.

Alternatively, you could have an option to always add to the jumplist no matter what. The upside of this would be extremely simple code, the downside is cluttering the jumplist with some unnecessary entries. I would rather have a bit of clutter on the jumplist than have something not be on it that I wish was there, but obviously that's personal taste.

If you're willing to go this simpler route, I threw together a quick patch:

diff --git i/autoload/targets.vim w/autoload/targets.vim
index 699b7fe..82a4eb7 100644
--- i/autoload/targets.vim
+++ w/autoload/targets.vim
@@ -119,7 +119,7 @@ endfunction
 function! s:selectMatch()
     " if the match starts below the current line or ends above the current
     " line (the cursor is not linewise inside the match)
-    if s:oldpos[1] < s:sl || s:oldpos[1] > s:el
+    if s:oldpos[1] < s:sl || s:oldpos[1] > s:el || exists('g:targets_jumplist_always')
         call setpos('.', s:oldpos) " move cursor to old position
         execute "normal! m'" |     " and add it to the jump list
     endif
diff --git i/doc/targets.txt w/doc/targets.txt
index 8ffb64b..65fb213 100644
--- i/doc/targets.txt
+++ w/doc/targets.txt
@@ -389,6 +389,7 @@ Available options: ~
     |g:targets_pairs|
     |g:targets_quotes|
     |g:targets_separators|
+    |g:targets_jumplist_always|

 ------------------------------------------------------------------------------
                                                               *g:targets_aiAI*
@@ -445,6 +446,14 @@ letter alias. To set 'c' as an alias for comma, allowing such commands as

     let g:targets_separators = ',c . ; : + - ~ _ * / \ |' ~

+                                                    *g:targets_jumplist_always*
+Default:
+    not defined by default ~
+
+If defined, always add current cursor position to jumplist before performing a
+text object motion. The default behavior is to only add to the jumplist if the
+object starts below or ends above the current line.
+
 ==============================================================================
 NOTES                                                          *targets-notes*

Using Vim 7.2 and targets.vim commit #401b1b9, if I change the text inside double quote marks using ci" and then try this again inside another pair of double quotes using ., it replaces the wrong text unless (a) the text is the same length, and (b) the cursor is in the same place within the text.

Let's select an argument with visual-mode operator!

Problem 1

Expected:

                  +
function(a, 33, Rstyle="calls, with commas inside strings, are OK")
              +--------------------------------------------------+

Actual:

                  +
function(a, 33, Rstyle="calls, with commas inside strings, are OK")
              +-------------+

Whereas this works as expected:

               +
function(a, 33, [1, 2, 3, 4, 5, ], 61234, V="one, two", )
              +-----------------+

Conclusion: the argument text object is smart enough to ignore nested argument objects, but not smart enough to ignore pair-text-objects and quote-text-objects as arguments.

Problem 2

Expected:

                                    +
function(a, 33, Rstyle="calls, with commas inside strings, are OK")
              +--------------------------------------------------+

Actual

                                    +
function(a, 33, Rstyle="calls, with commas inside strings, are OK")
                             +--------------------------+

Perhaps a nesting bug, so I repeat the text object in visual-mode (the previous range is above, the final below):

                                    +
                             +--------------------------+
function(a, 33, Rstyle="calls, with commas inside strings, are OK")
+

Conclusion: this is just plain broken.

For a bunch of the operators, there’s a tag for the summary, and then for the detailed help for that specific operator. e.g. Ia is tagged on both line 100 and 436. This upsets :helptags a bit: :h Ia still jumps to its help on line 100, but making the tags in the first place gives some errors.

(I didn’t fix it myself and do a pull request since I’m not sure which one to change and what to call it…)

" -- cursor -------|
call foo("bar", "baz", foo("bar", "baz", "bla", "robot"), "bla", "robot") 

with

v2aa

causes

E117: Unknown function: getcmdwintype                                                          
E15: Invalid expression: getcmdwintype() ==# ""                                                
Error detected while processing function targets#x..<SNR>106_abortMatch:    
line    2:    

on vim 7.4.273

I was having an issue changing inside # separators, for example changing 'that' in thing#that#does#stuffI would put my cursor inside the word 'that' and press ci# expecting to be left in insert mode with thing##does#stuff. sadly this action doesn't seem to work (nor does any other map containing a #)

The plugin in seems to be running fine, calling `:exe 'norm ci#' in the same situation seems to work as expected.

On my keyboard # is fired by pressing ⌥+3 (equivalent of ALT+3). there might be an escape char issue?

setting let g:targets_separators = ', . ; : + - = ~ _ * # / | \ & $' from either Ex or my vimrc seems to fix the issue but loading the plugin without with this setting behaves as above.

This solution works for me, but there might be an issue somewhere.

I have in my vimrc set virtualedit+=onemore. This seems to create issues (the operated-on text is larger than expected).

Inspired by #80.

It could be useful to have mappings like

• ciF" to change inside the first quotes in the current line
• ciL" to change inside the last quotes in the current line

This should not be confused with the current word last meaning previous.

I think the current L and N mappings are not really useful, so I think we could use F and L for this.

Any comments?

Thanks for the plugin! It's really great.

When I enabled targets.vim and do a ci' for example the whole screen redraws. When I disable targets.vim this isn't the case anymore. It's only noticable when I edit .php files. I've tried python and css but they don't have this issue.

This is my code

nnoremap <A-f> [I:let nr = input("Find: ")<Bar>exe "normal " . nr ."[\<C-I>"<CR>

My cursor is on the dash in <C-I>. If I type di<, the line changes to

nnoremap <A-f> [I:let nr = input("Find: ")<Bar>exe "normal " . nr ."[\<C-I>"<>

instead of

nnoremap <A-f> [I:let nr = input("Find: ")<Bar>exe "normal " . nr ."[\<>"<CR>

as expected.

Bug: vi' or vib exits the Command-line window.

In this state:

cursor              .
  line    <a href="{link}">{title}</a>

If I do daB or da}, {title} is what gets deleted, not {link}.

This is true if you replace {} with (), too.

Just generating discussion but I'm a fan of the following additional text objects:-

• https://github.com/gaving/vim-textobj-argument
• https://github.com/kana/vim-textobj-line
• https://github.com/kana/vim-textobj-indent

I'm thinking the argument one is superseded by targets.vim's separator objects, but any chance of either line or indent making their way in?

Doing any command against "", [], '' and probably more (haven't tested all of them)
However, now it seems the error is happening on non-empty text objects.
Weird!

Let me know if there's any further information you'd need from me.

Is there a reason you've made a for quotes behave more like A for everything else? I'd really love to have a for quotes where it doesn't select whitespace.

Basically make it so the chart for a list of quotes from the cheatsheet looks like this:

                    ..........
a ' bbbbbbb ' ccccccc ' dddddd ' eeeeeee ' fffffff ' g
  ││└ IL' ┘│││└ Il' ┘│││└ I' ┘│││└ In' ┘│││└ IN' ┘│││
  │└─ iL' ─┘│└─ il' ─┘│└─ i' ─┘│└─ in' ─┘│└─ iN' ─┘││
  ├── aL' ──┼── al' ──┼── a' ──┼── an' ──┼── aN' ──┘│
  └── AL' ──┼┘        └┼─ A' ──┼┘        └┼─ AN' ───┘
            └── Al' ───┘       └── An' ───┘

I think I can see how to add it myself (from an admittedly brief look through s:createQuoteTextObjects()), but based on how easy it would be for me to add, it makes me think you've made this a deliberate choice.

At the very least, I can see that adding this would make the plugin work differently for most of its existing users. But seems like the consistency across the different objects would make the change worthwhile. Maybe there could be some sort of option to get the old behavior.

Would you accept any patches related to this?

As discussed in #57 (comment).

Doubling a separator in the list should make da$ select both separators.

let g:targets_separators = ', . ; : + - = ~ _ * # / | \ & $$'

As requested by @edkolev in #14 (comment).

Line 352 of targets.txt contains two instances of AL$. The first one should be AL&

How to selectively disable default bindings for the upper case versions of i,a + operator? The documentation says that all four bindings have to be set for every operator.

In particular

" add expression mappings for `A` and `I` in visual mode #23
function! s:addExpressionMappings()
    xnoremap <expr> <silent> A targets#uppercaseXmap('A')
    xnoremap <expr> <silent> I targets#uppercaseXmap('I')
endfunction

overrides other plugins' functions such as

https://github.com/kana/vim-niceblock

which prepends and appends text in a visual selection by I and A.

Great plugin! Sadly, none of the last pair mappings seem to work for me.

Here are some examples of the behavior I am seeing. Assume an otherwise empty buffer for each example, with the cursor located at line 1, column 1. The first line is the only text inside the buffer. The second line is the normal mode command I entered. The third line is my expected result. The fourth line is the actual result.

('one', 'two', 'three')
dil'
('one', 'two', '')
('one', two', 'three')


(one) (two) (three)
dil(
(one) (two) ()
(one) (two) (three)

Any thoughts?

vi,
           +
a , b , cccccccc , d , e

... as though there was a timeout.

Vim, by default, doesn't treat multiline strings similar to multiline braces. For eg. in case of

"Some text |here
and more text here"

where | denotes the position of the cursor. Pressing di" doesn't delete the entire string.

Would it be possible to treat ', " and ` similar to braces in this regard?

It seems that while in visual mode, when pressing I or A it immediately performs the action as if it were in normal mode (aka going to the beginning of the line and going into insert mode)

This only happens in visual mode.

vI<text object> and vA<text object>

performed my tests on:
( foobar )
' foobar '
( foobar ) .
' foobar ' .

Is it possible to add tag-blocks support?

I'm opening a separate issue from #14 because that one is referring to 3rd party text objects.

As suggested by @EPNGH in #14 (comment).

Say I have this line, because I just installed targets.vim and am playing:

asdf;asdf;asdf;asdf;asdf;asdf;asdf;asdf;asdf;asdf;asdf

With my cursor somewhere in that line, I start typing da; over and over again until I end up with this:

asdf;asdf

Pressing da; again doesn't do anything, of course, because there is only one semicolon left. But there is no error, and the command is entered into the undo history. For instance, if at this point I (ineffectively) hit da; three times, I have to hit u three times to "actually start undoing" and get my text back to where it was before the last successful da;.

Hi,

When using vi( for example, the last character is not selected when selection=inclusive, which is the default setting when vim is run on windows.

In my configuration, targets takes around 115ms to load, which I consider unacceptable for a single plugin.

Is there a way to iterate faster so that the load time is not so long?

Cheers!

After updating targets, I got a ton of messed up mappings because the parts of g:targets_aiAI and g:targets_nlNL I replaced with spaces now get mapped, e.g.

silent! execute 'onoremap <silent> <unique>' . s:A . s:L . triggerMap . "LA')<CR>"

executes

onoremap <silent> <unique>  % :<C-U>call targets#o('%LA')<CR>

so now % by itself is mapped to call targets#o('%LA').

As tried in #3, but without breaking #5.

https://asciinema.org/a/9101 - in which I thrash around trying to use these text objects without very much success

As far as I can pin down, separator objects don't respect their context very well. IE a comma-separated list extends through parentheses. I'd love to be able to "da," to delete a function parameter, but this doesn't work for the first or last right now.

If parentheses-respect were an option, that'd be OK, although it'd be nice if you could pick sane behaviour based on filetype.

Besides (), I'd also expect a comma list to end at [], {}, "", '', colon, semicolon and almost certainly others.

Expected:

v2in.
       +
"a" . "b" . "c" . "dd . ee . ff" . "c" . "b" . "a"
                 ++++++++++++++++

With behaviour similar to that of pairs text objects:

v3in.
       +
"a" . "b" . "c" . "dd . ee . ff" . "c" . "b" . "a"
                 +++++

Be extension, [count] would break out of separator objects nested in quotes or pairs:

v2i.
                        +
"a" . "b" . "c" . "dd . ee . ff" . "c" . "b" . "a"
                 ++++++++++++++++

There is a noticeable lag that this plugin introduces when inserting before or after a block selection.

To reproduce create a file like this:

asdf=
asdf=
asdf=

Visually select all the = signs, execute shift+A. There is a noticeable lag before it drops you into insert mode.

Is there any possibility of reducing or eliminating this lag?

Hi, I started using vim-textobj-line again and I realized that its mappings conflict with that of this plugin. Since, I've been using n/l for next/last for quite some time now, I changed textobj-line's mappings to use _ since _ kind of represents a line-textobj. However, this still conflicts with targets.vim

Would it be possible to use :silent! execute and <unique> while creating the maps so that any user-defined mappings are not overwritten?

I was also reading your response here and was intrigued by the idea of using n/N instead of n/l. Is this something that you have tried or plan on supporting? If not, I'll just hack it in my work-area and see how it feels.

Thanks for an awesome plugin :) 👍

Almost immediately, I noticed that I was getting weird behavior from this plugin when using some surround commands. For instance:

(asdf)
  ^ caret

ysi) would immediately put a colon in front of the a. It turns out this is caused by targets#omap doing extra cleanup. ys expects additional input after the text object, much like c, so the check in s:clearCommandLine should test for 'g@' as well. Unfortunately, that's about the best that can be done (I think), even though other custom operators may not expect more input.

Hello, targets would be less intrusive if it could avoid overwriting i and o in visual and operator mode.

For example, even if target is not used, such as for iw in operator mode, it caused a bug in #92

Another point is that the check

" [rectangle]
onoremap <unique> ar  a]
xnoremap <unique> ar  a]
onoremap <unique> ir  i]
xnoremap <unique> ir  i]

if ir/ar is already mapped in operator/visual mode does not work, because targets overwrites i and a.

I often encounter situations where I want to quickly change text in quotes or brackets (or any other delimiters), and then jump back to where I was before. For example, if the cursor is currently somewhere on the first line of the below, I may want to change the hello world text, then go back to whatever I was doing back on the first line.

int c = 0;
c++;
int x = 2 * c;
string s = "hello world";

It would be nice if this was possible by just hitting <C-o>, and I think it would be handy if targets.vim had the option of adding the current location to the jumplist before seeking to a text object.

I noticed this first in my .vimrc because I have some fun bindings in there and apparently they make the plugin act funny... Minimal working example here, X being cursor position.

let g = {
     \ { arg 1 },
    X\ { arg 2 },
}

If you type the command ci{, the resulting output should (intuitively) erase "arg 2" and leave you in the appropriate spot in insert mode. The current behavior ends up with

let g = {
X
}

However cin{ works fine, and cil{ performs on the curly braces surrounding "arg 1" as expected.

The second bug is similar.

X beautifulCode text [ things ] ; 
...
(50 lines down the vimrc later)
...
noremap p ]p

Typing ci[ from the cursor position erases EVERYTHING in-between the first bracket and the one at the last line, leaving the result:

beautifulCode text [X]p

Typing cin[ works properly, however. Additionally, it's also worth noting that vim's built in % matching command seems to automatically match the first line with the "matching" bracket 50 lines down, just like your plugin does.

It seems to me that, intuitively, the plugin should automatically seek within the line first, and then +/-1, before going to the "largest area currently within". However, that does raise the question of how you would operate on the entire surrounding curly brace (e.g. in example 1) if the plugin defaulted to line search, so perhaps a proximity setting might be in order? If I'm within, say, 10-15 characters of something more narrow that matches the command, then act on that instead of the wider selection, and if I'm further away from it (say, at the other end of a line of code), the plugin should act on the larger area.

An example:

let g = {
    [X]more text, and other fancy things, probablyLongEnoughToBeAJava[Y]NameNow { arg },
}

If the cursor was at, say, the position of [X], then ci{ would act on the curly braces surrounding the entire line, whereas if it was at the position [Y], ci{ would act on the braces surrounding "arg".

One last issue. If I have some text like:

X  ..... 
(30 lines down)
<foo> things

And I press ci<, the cursor will jump all 30 lines down and give the result <X>. This is cool, but I don't know if having the text searching being unlimited is really a good idea, I imagine it would be horribly frustrating to hit the wrong key and accidentally end up somewhere 200 lines over, in a larger codebase. Perhaps a vertical limit of, say, ~15 lines would be more appropriate? Of course this and the line-wise priority could be adjustable/able to be turned off by the end user, or whatever.

Sorry for the wall of text. Also not quite sure whether to call this a bug or "thang1thang2 is weird and likes weird things and makes weird suggestions"...

I'm still wrapping my head around the seeking in targets.vim, so help me out here. If I have the following bit of code in file...

<div>
    <span>A</span>
</div>

And my cursor is at the beginning of the middle line, and I type vit, it seems to me that it should select the entire middle line, and not just A. Can you reproduce this? Is this the correct behavior?

Let * = cursor position.

Found:

*hello

Then hitting yiwP gives

hello*o

Expected:

hello*hello

could you add such argument for C language:

for (i = 0; i < 10; i++)

cia / caa can change i = 0 or i = 0;

I mean ia / aa can select argument between ; just for for loop of C .

Thanks

Line 296 in targets.txt causes vim to issue the following error when generating help tags:

E154: Duplcate tag "A&" in file targets.txt

The line in question contains:

I~ I_ I* I/ I| I\ A&                     *I~* *I_* *I/* *I|* *I\* *A&* *Istar*

I believe those instances of "A&" should be "I&"

I'm running Vim 7.2, and as such, when I attempt an invalid targets.vim action, I get the following error (since Vim < 7.3 doesn't have undotree):

Error detected while processing function targets#match..targets#handleMatch..targets#abortMatch:
line    5:
E117: Unknown function: undotree
E15: Invalid expression: undotree().seq_cur
line    6:
E121: Undefined variable: undoseq
E116: Invalid arguments for function feedkeys

The documentation reports the following as the default:

let g:targets_pairs = '()b {}B [] <>'

But as implemented, it is:

let g:targets_pairs = '()b {}B []r <>'

(The former seems like a better default, as the ir/ar text objects conflict with https://github.com/nelstrom/vim-textobj-rubyblock.)

Given call foo("bar", "baz", "bla", "robot") and any argument text input with counts such as v2aa, c3ia, the cursor is repositioned to the start-of-line and no object is modified by the operator.

One of my common use cases with "around" objects is to grow a selection several times, e.g. to see the extents of a structure in a JSON file, and then its containing structures. In this example, starting anywhere in the dots on the cursor line, I should be able to vaB to select the inner {} structure, and then aB to grow to the outer one directly from there.

cursor          ............
sample {"foo": {"bar": "baz"}}
vaB            └────────────┘
aB     └─────────────────────┘

However, this does not currently work against tag v0.1.2.

If

let g:targets_separators = '$$'

then in character-wise visual mode hitting al$,an$ will only select the leading $ as if

let g:targets_separators = '$'

In contrast, hitting a$ select the trailing $ as well.

First of all, thank you for the fantastic work on this plugin! I've been trying to cib from the start of an if () line for ages like you can with ci" and now I finally can!

Here's my bug report. In the context of:

    if (foo) {
    bar += 1;
    }

with the cursor on bar, executing >iB results in:

    if (foo) {
        bar += 1;
        }
//      ^-- wrong

where it should be:

    if (foo) {
        bar += 1;
    }
//  ^-- right 

I don't really use the seeking with curly braces so I've just disabled it for now, but thought you'd like to know :)