Vim: Delete command sometimes not triggering in macros

[danielbarla]

What did you do?

Recorded a macro as follows:

qq/:[enter]d$q

Then ran it using @q

What did you expect to happen?

I'm expecting the macro to find the next colon character :, then delete till the end of the line.

E.g. given the file:

test1: 'asdf',
test2: 'asdf',

I'd expect it to look as follows after running the macro (with the cursor in the beginning of the 1st line):

test1
test2: 'asdf',

What happened instead?

The macro seems to abort just before the delete command. The find : command is executed, and the cursor rests on the :, but the delete is not triggered.

I've ran across similar issues with delete commands in the middle of macros, it always seems to be the delete / change command which causes the problem. (e.g. dw, c$[esc] seem to behave identically). The colon character here was just an example, it doesn't seem to have much of a role in this issue. In other macros where I had a similar problem, the navigation used before the delete was something other than /, so that also is unlikely to be the problem.

Also, having the delete command at the front of the macro seems to work, so e.g. d$/:[enter] seems to complete successfully.

Technical details:

• VSCode Version: 1.7.2 (though I experienced it in earlier versions too, definitely 1.7.1, perhaps earlier)
• VsCodeVim Version: 0.4.3
• OS: Windows 10 (Enterprise)

[danielbarla]

Just to clarify the word 'sometimes' - the issue is not intermittent in nature, so once a macro has been recorded which has this problem, re-running it will always have the problem. I used the word since in some situations the delete command can work, I'm just not sure what the exact conditions / rules are.

[rebornix]

I think that the catch is macro recording somehow ends with there is a search. I didn't take a careful look at the corner cases but I'd like to have it fixed when users run into problems.

[danielbarla]

@rebornix - I quickly tested that idea, but unfortunately it doesn't seem to be the case.

E.g. with the same example file, qqwd$jbq behaves pretty much identically (aborts just before the d$).

If additional info helps, I've encountered similar issues with several different macro attempts involving d, c, y, and with a variation of navigation options, searches, word or line navigation, etc. Most macros seem to abort as soon as they encounter those actions. This seems to happen on both installations I'm actively using (one Win 7, one Win 10).

[xconverge]

aha this is actually pretty simple for why it is happening

when you select q1, it is recording a macro into register 1. Now as soon as you do something that puts something into a register, it destroys the macro kind of, it is not decoupled correctly I don't think

[danielbarla]

Looking at the referenced issue and the comment above, I've tried testing a few alternative macros - the results are a bit confusing.

For a quick test regarding @xconverge 's comment, I've tried recording the macro into another register (say w), but still ran into the same problem. So I'm guessing that the register confusion must be happening internally in the implementation, and not easily circumvented by the user.

I've also noticed that restructuring the macro so that the delete is the first action, i.e. something like qqd$^jf:q, the delete itself does work. On the other hand, this macro also doesn't behave as expected either, but in a completely different way. I'm going to include it here, in case it's caused by a related problem. So, starting with the file:

test1: 'asdf',
test2: 'asdf',
test3: 'asdf',
test4: 'asdf',

and issuing the new macro from the first :, it executes as expected and lands on the 2nd line's :, visually. But then running the macro again results in the preceding 2 character being deleted as well. Again we land on the expected :, but running the macro yet again now deletes two additional characters, etc. We end up with:

test1
test
tes
te

Which is pretty unexpected. Testing in gVim seems to confirm the macro should work. VsCodeVim version was 0.5.3 in this case.

[xconverge]

@danielbarla yes it is definitely happening internally

[johnfn]

Fixed.

[danielbarla]

Can confirm, problem is gone in version 0.6.3, both the original test case and the subsequent one I mentioned. (A heartfelt thank you to everyone involved!)