Reputation: 455
If I do q e CTRL+W Right Arrow q, it binds the command "move one window to the right in the split" to the e key.
The macro for this as found by "ep is ^W<80>kr
.
If I want to type this, I would do CTRL+K EB for ^W
, CTRL+KPA for <80>
, and simply kr for kr
. Then, with "eyy, I could yank this command sequence into the e register.
However, I have come to realize that the Padding Character (PAD) <80>
generated by the CTRL+K PA method does not actually work, and breaks the macro.
Why does the typed Padding Character not work? What makes it different from the Padding Character generated by VIM when doing the command while recording? They look exactly the same, and VIM even applies the same colour scheme to them.
Edit 1
I've also tried ga on the VIM generated <80> and my typed one. It said that they both are <<80>> 128, Hex 0080, Oct 200, Digr PA
, where the inner <80>
is blue and the outer <>
is white.
I confirmed that it is the PA digraph causing trouble by editing and testing the working string piece by piece until it broke.
Upvotes: 1
Views: 44
Reputation: 196546
The macro is stored in, not "bound to", the register, not "key", "e
: you don't press e
to execute it, you press @e
.
Now… Vim unfortunately adds quite a lot of meaningless garbage to its recordings. Those <80>kr
, <fd>a
, etc. artefacts create way too much noise when editing or simply trying to make sense of a recorded macro. There is no easy way to prevent Vim from adding them or to get rid of them in an existing macro. Even a substitution like this doesn't work:
:call getreg("e")->substitute("\%u0080", "", "g")->setreg("e")
because, for whatever reason, those <80>
s in the macro are not really <80>
s and they are basically unsearchable.
And the corollary, as you found out, is that the <80>
s you insert manually are not the same as the <80>
s you would expect in a macro.
What a mess.
The important thing to keep in mind when dealing with macros, is that those <80>
s and friends are pure garbage that serves no purpose whatsoever. You can completely ignore them and move on with your life if you never edit macros manually but, if you do, you should remove them whenever you get a chance and never try to add them.
In this case, Vim used <80>kr
as an internal representation of <Right>
, which is as noisy as it gets. Rewriting the macro as:
^Wl
would make it more readable without affecting its functionality. And this would be the most sensible way to change your macro so that it cycles windows in the other direction:
^Wh
To repeat myself:
Upvotes: 1