using the -W option of vim

the -w and -W options of vim have theoretically the following effect:

-w {scriptout} All the characters that you type are recorded in the file "scriptout", until you exit Vim. This is useful if you want to create a script file to be used with "vim -s" or ":source!". When the "scriptout" file already exists, new characters are appended. See also |complex-repeat|. 开发者_如何学运维 {scriptout} cannot start with a digit. {not in Vi}

-W {scriptout} Like -w, but do not append, overwrite an existing file. {not in Vi}

But when I do this, the {scriptout} file will always begin with a hexadecimal sequence like 80 fd 60 (sometimes it is 80 fd 62).

I am using gvimportable.exe 7.3 from portableapps.com. With the -u NONE switch, it does the same.

What is this “magic number” for? Under Windows with gvim.exe I cannot replay my scriptout until I have removed those three leading bytes…

It seems that this feature, which could be very useful, is poorly documented.

Thank you for your answers.

(This answer is probably fragmented significantly, it took me a while playing around - I wanted to find a solution too because it intrigued me - not just the bounty of 200 :P. It more or less shows my train of thought and experimentation.)

I can now reproduce it with gvim on Linux, which is /usr/bin/vim.gnome -g; running as vim -g does just the same.

Delving into the code: (futile in this case, but fun to do and to learn how to do)

I've looked through the source code and I can now explain it somewhat (but not usefully!); it gets the outfile FILE (src/globals.h:1004) set (src/main.h:2275); this is then written to in src/getchar.h:1501, in the updatescript method which is used by gotchars (line 1215) which is used by vgetorpeek, which is used by vgetc and vpeekc... (no, I don't know where this is going!) then these are used in a number of places.

Anyway, I suppose the key is somewhere in src/gui.c, but I don't know where at the moment! It's also possible that some key sequence is being "sent" (physically or virtually, I don't know), but seeing as the issue is the same across platforms it would seem more likely to be a Vim issue than otherwise.

Interesting situations leading to a probable explanation:

It's also worth while noting that if you automatically quit, gvim -u NONE -w scriptout -c quit (:quit after loading) or gvim -u NONE -w scriptout -c quit (instant :quit, never shows GUI), the file scriptout is left empty.

Additionally, if you open gvim and then close it using the X button, pressing no keys:

0000000: 80fd 6280 fd63 80fd 62                   ..b..c..b

If you open gvim, click away, click back and use :q:

0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a  ..b..c..b..,...:
0000010: 710d                                     q.

So I think it's the window events are internally translated into something else. 80 fd 62 is the open sequence and 80 fd 63 80 fd 62 is the close sequence.

I've found another way of triggering 80fd as well, which leads me to thing it's some sort of "user has access to the window"; by default with GNOME in Ubuntu, Ctrl+Alt+S does something with the window (can't remember what it's called; slides it all up into the title bar, app inside loses keyboard control etc.). gvim ... (you know the arguments!), i<Ctrl+Alt+S (contracted) Ctrl+Alt+S (expanded) >Esc Z Q produces this for me:

0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51    ..bi<..c..b>.ZQ

Summary: so there we have what I believe is the solution; gVim catches the window messages in some form and - whether it should or shouldn't - puts them in its scriptout. If you think it shouldn't (or would like to know why they're left in or if they're even meant to be or whether you should care at all), ask on the Vim list, I think.

My best guess is that this is a bug in the GUI code of gVim.

Using gVim 7.3, if I run gvim -u NONE -W scriptout then I see the problem, but if I run vim -u NONE -W scriptout then the unwanted bytes are not present.

I also tested Vim 7.2 from the shell in Linux, the version of Vim included in Snow Leopard (7.2), and the GUI and terminal versions of MacVim 7.2 (with mvim -W and /Applications/MacVim/Contents/MacOS/Vim -W, respectively) and they all worked correctly.

Someone has done the hard work for us in the vimgolf project, in particular this well-commented file: https://github.com/igrigorik/vimgolf/blob/master/lib/vimgolf/lib/vimgolf/keylog.rb

0x80 in escape sequence for special two-byte codes. In this case they represent gvim focus events. See here:

      # If you use gvim, you'll get an entry in your keylog every time the
      # window gains or loses focus. These "keystrokes" should not show and
      # should not be counted.
      "\xfd\x60" => nil, # 7.2 Focus Gained compat
      "\xfd\x61" => nil, # Focus Gained (GVIM) (>7.4.1433)
      "\xfd\x62" => nil, # Focus Gained (GVIM)
      "\xfd\x63" => nil, # Focus Lost (GVIM)