using the -W option of vim

Question

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.

Connecticut

When I tested using the -W option, vim did not add any extra characters to the start of the file. You should try again without your .vimrc using vim -u NONE -W somefile – Floria

That's what I did… still, vim -u NONE -W scriptout, ZQ and xxd my_scriptout will show 80fd 605a 51 (..`ZQ) – Connecticut

I looked at this a couple of weeks ago and couldn't reproduce it on Linux... now that I know you're using my gVim Portable (yay!) I'll try again on Windows and see if I can figure it out. (Tomorrow, not today.) – Particularism

Wait, I did reproduce it with Linux with gvim... it does output 80fd 60 with -w or -W, just not with vim. – Particularism

Answer 1

(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.

Particularism

Note that this testing was done entirely on Linux once I discovered the issue was manifesting itself there as well as on Windows. If you want, I can play around with it in a similar manner on Windows, or you can. I think you'll find approximately the same thing: doing things with the Window itself puts things into the scriptout. – Particularism

Answer 2

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.

Strake

thank you for your answer. I am probably bound to look into the code to find why it does so. Could you try this under Linux too? – Connecticut

@Connecticut Yup, works fine on Linux, and both from the terminal and GUI on OS X. I edited my answer to show this. – Strake

Answer 3

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)

Henriettehenriha