2

When I try to record a macro that involves hitting Esc the following bytes are added to the register <80><fd>a for example if I type qq<Esc>q when I :echo @q I get back ^[<80><fd>a. I understand that ^[ is the escape character. I would expect the register to only contain ^[ but that is not the case.

The extra bytes do not hinder the execution of the macro but does make it a bit difficult to edit the macro.

I have noticed that if I am quick enough (don't allow for the timeout) to record the example macro does not add the extra bytes.

Is this expected behavior? Is there there a way to have it behave as expected, preferably without disabling the timeout feature?

These are my timeout related settings:

timeout
nottimeout
timeoutlen=1000

Not sure if it matters but I am using vim within WSL (Ubuntu) and the Windows Terminal.

1
  • I did find a few places that <80> is mentioned: :help i_CTRL-R says it's for special keys; :help getchar() says similar; also :help expr-quote. Also right above :help :map-cmd. Nothing on <fd> though
    – D. Ben Knoble
    May 13 at 22:48
1

Key codes starting with <80><fd> are called KS_EXTRA keycodes and they normally encode keystrokes or events that are not typically supported by a terminal (or have not traditionally been supported by terminals in the past.)

These include shifted Function keys, Control arrows and then even events such as mouse click, scroll wheel, etc.

I believe that <80><fd>a (a is the same as <61> in hex, or 97 in decimal) used to be a "Focus Gained" event. Here it gets a bit complicated, because it seems previous versions of Vim (7.4) simply listed the KS_EXTRA events in an ordered enum and let the compiler assign them actual numbers. At some point, one of the entries was removed and all entries that followed were shifted... So it seems KE_FOCUSGAINED is now 98 (which would match <80><fd>b), but 97 (<80><fd>a) is still listed as KE_NOP, presumably for compatibility with recordings from previous versions of Vim.

Why are you seeing focus events on your environment? I'm not sure I can tell for certain... These events are primarily used by GVim where you'll get these kinds of events since you'll be interacting with the windowing system directly. I believe some terminals make it possible for applications running on them to detect whether focus was gained or lost and that Vim is somehow receiving these events. It's also possible that the <Esc> key is somehow triggering this, or that this is a workaround on <Esc> to detect whether this is actually an <Esc> key press versus the beginning of an escape sequence... I have witnessed these <80><fd>a events before (running on a terminal on Linux), so I know that they do happen just as you described and not only on WSL.

For reference, see keylog.rb from Vimgolf which parses Vim keystroke recordings into human readable forms (the specific sequence <80><fd>a was source of a longstanding issue finally released in Vimgolf client 0.4.9).

See also the KE_NOP entry in keymap.h in Vim 8.2 source code.

5
  • Thanks for the context around the bytes themselves. I don't think you answered my question though, which is whether those bytes are expected to be inserted or if it is a bug? Sounds like Vimgolf has had to create a workaround for it, so I guess it could be considered a bug.
    – Kasper-34
    May 14 at 18:41
  • Yes, those bytes are expected, it's not a bug. Vim will interpret and record every event it receives. Since the vast majority of those will be key presses, these are ignored during replay, and you won't see them unless you're inspecting macros or script out files, they will stay out of the way most of the time... But yes, they're expected and not a bug. Not sure how I could improve the answer to make that more clear... Do you have a suggestion on how to edit to improve it?
    – filbranden
    May 15 at 19:57
  • You mentioned you have witnessed the bytes before on a terminal on Linux. Does that mean you don't see them all the time? Were you able to reproduce my example? My assumption is others don't experience the additional bytes when recording a macro. If my assumption is correct, then I'd like to know why I experience it and others don't. If I am wrong then vim just adds the KE_NOP bytes and I can live with it.
    – Kasper-34
    May 17 at 16:59
  • I witnessed these mostly in dealing with VimGolf. The previous version of the client (0.4.8) was missing the <fd-61> fix so I saw that in my submissions. VimGolf uses the -W {scriptout} argument to log keystrokes to a file, so not exactly recording a macro... But probably using the same code path. With VimGolf I also often need to switch windows (see what the expected result looks like), so I also connected these events with gaining/losing focus. I've had situations where the problem didn't reproduce using the same keystrokes.
    – filbranden
    May 17 at 19:27
  • So, in short, yes this is normal. You think of Vim as receiving/recording keystrokes, but in fact it's receiving/recording events. 99% of those are keystrokes, so most of the time it's easy to think that's all there is... And the non-keystroke events often do nothing when replaying, so most of the time unless you're looking for them explicitly you won't find them... So, yeah, they're normal, it's mostly fine to ignore them.
    – filbranden
    May 17 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.