"inner tag" pending operator broken

[dylnmc]

it doesn't behave properly:

1. vim --noplugin for instance

2. :setf html

3. i<div></div> esc

Now, if you do _cit it will appropriately place the cursor inside of the tag, as it should.

However, if you do 0f<cit then it will effectively do cat (change around tag), as it deletes the entire tag. The problem is that if the cursor is position on the start of the closing tag, and the tag is emtpy, then cit will not work properly, but instead it deletes the entire tag not just the inner tag.

I have also noticed some bugs when the tag is empty for tpope's vim-surround and also with (presumably) the default xmap (whatever it is ... vit).

For example (with vim-surround), if you use the above example (<div></div>) and do:

csttimg

(that's cst for change surrounding tag then another t for tag again--we're trying to change the divs to imgs--and finally img for the ... well, "img"--the tag we're changing it to) ... this does not work when the tag is empty, but it works when there is at least one character inside the tag.

[tonymec]

1. it case:
   From :help tag-blocks:

The normal method is to select a <tag> until the matching </tag>.  For "at"
the tags are included, for "it" they are excluded.  But when "it" is repeated
the tags will be included (otherwise nothing would change).  Also, "it" used
on a tag block with no contents will select the leading tag.

When you are on the < of the closing tag of an empty block, IIUC you're in the case of ...otherwise nothing would change so it includes the tags.

The help paragraph is a little mealy-mouthed, and not perfectly clear, but I think that what you experience is expected behaviour. @brammool (or someone), please correct me if I'm wrong.

2. st case:
   I cannot find in the help any documentation about an st object. The only way I know about to change the interior of a <..> is to place the cursor inside the angle brackets, or on one of them, and then use an "inner angle bracket" object, e.g. ci<. I don't know where you got that cst idea from, maybe a third-party ftplugin, named (e.g.) .vim/ftplugin/after/html/something.vim? (--noplugin inhibits global plugins but not filetype plugins if filetype detection is enabled, which is usually the case when Vim is invoked without -u NONE: then looking for your vimrc is not inhibited, if found it will normally include a :filetype plugin [indent] on statement, and if not found Vim will source the $VIMRUNTIME/defaults.vim which does include such a statement.)

Best regards,
Tony.

[andymass]

As Tony says, this is in some sense expected by analogy to vit on the closing tag's <. That is, if you are in visual mode, the smallest region is 1 character and it tries to expand this region.

"it" used on a tag block with no contents will select the leading tag.

Doesn't actually seem correct, since cit anywhere but the < will enter insert mode inside the tag.

The following patch would fix the inconsistency described in this issue for operators while keeping the behavior in visual mode the same:

--- a/src/search.c
+++ b/src/search.c
@@ -4108,7 +4108,8 @@ again:

        /* If we now have the same text as before reset "do_include" and try
         * again. */
-       if (EQUAL_POS(start_pos, old_start) && EQUAL_POS(end_pos, old_end))
+       if (EQUAL_POS(start_pos, old_start) && EQUAL_POS(end_pos, old_end)
+               && VIsual_active)
        {
            do_include = TRUE;
            curwin->w_cursor = old_start;

[dylnmc]

@tonymec st is a complex text object provided by vim-surround (tpope plugin). I find myself trying to cst an empty tag nearly every day only to find that it doesn't work. If this is a vim-surround problem, then maybe I should raise the issue there (I bet it already has been), but I feel like it's a vim issue and not a vim-surround issue.

@andymass I am not quite following, but do you think that this would fix the issue with vim-surround (eg csttNEWTAG)? Thanks for the prompt reply and looking into it. T'would be nice to fix any inconsistency with it.

[andymass]

@dylnmc, no, that patch would only change the first issue which you describe. I don't think the vim-surround issue is related because it happens for empty tags no matter where the cursor is, unlike the other issue which happens only when the cursor is on the closing tag's <.

Specific plugins for the most part are off-topic. So, while it might be related to a vim limitation of empty text objects, I think that should be a separate issue. I don't know exactly why vim-surround won't work with empty objects.