# How should vim answers be scored?

I like vim a lot. I've been golfing with it a lot recently. We already have clearly established that vim is a programming language, but there aren't any clear rules on how to score vim answers. The main things that I want to clarify are:

• Do modifiers (shift, alt, ctrl, etc.) count as an extra keystroke? E.g. d is one keystroke, but D is two keystrokes. If so, do consecutive modifiers count?

• Are keystrokes directly comparable to bytes? As in, if a vim answer takes 20 keystrokes, and a pyth answer is 21 bytes, does the vim answer win? Are they comparable?

vim answers can be run from the command line as such:

$echo 'Input' > file.txt$ vim -u NONE '+normal (enter keystrokes here...)' '+wq' file.txt
$cat file.txt # output  Furthermore, vim interprets Ctrl+<letter> by bytes in the lower portion of the ASCII table (with A-Z encoded as 1-26, ex. Ctrl+C is \x03), Esc as \x1b, and some other Ctrl combinations from \x1c to \x1f. Alt+<anything> is the same character with the high bit set. As such, any keystroke corresponds directly to one byte. As a proof of concept, the one-byte vim "program" <C-a> (that is, Ctrl+A) takes input as a single number n and outputs n+1, and it can be run like so: llama@llama:~$ echo 10 > file.txt
llama@llama:~$vim -u NONE$'+normal \x01' '+wq' file.txt
llama@llama:~\$ cat file.txt
11


Note that the actual program is \x01, which is a single byte. This is a definitive mapping of keystrokes ⇔ bytes (in fact, when "running" a vim program via the command line, they are bytes); therefore, vim answers can be scored the same as any other answer.

• +1 for llama@llama (jk, I agree with this answer) – CAD97 Apr 26 '16 at 20:08
• @CAD97 that's his actual shell. – Rɪᴋᴇʀ Jun 15 '16 at 21:39
• @EᴀsᴛᴇʀʟʏIʀᴋ It has to be. I enjoy the fact that that's what the name of the shell is. – CAD97 Jun 15 '16 at 22:48

Modifiers should not count as an extra keystroke. If the challenge is specifically an challenge, this is different, and it should be specified either way by the OP. But vim answers to code-golf challenges should not count modifiers. Also, keystrokes should be exactly equivalent to bytes. Using this a standard has many advantages.

• It's simpler. We don't have to worry about consecutively holding down modifiers. Who wants to go to all the trouble to score that? a is one keystroke, D is one keystroke, <C-a> is one keystroke and <CR> is one keystroke.

• Another reason this makes sense is that vim answers can be ran as a string of text with a certain byte size, e.g. with

vim "+normal <keystrokes>"


Or, as Doorknob argued here, you could noremap your "program" to a key, and run it as a program.

• Internally, every keystroke corresponds to a single ascii byte. You can see this by logging vim keystrokes to a file with

vim -w log.txt


This logs keystrokes, even the unprintable ones with modifiers, such as <C-a> or <esc> to a single byte. Since keystrokes are just bytes that are entered slightly differently, why should they count differently?

If keystrokes were scored differently than bytes, this makes things unnecessarily complicated, for no real benefit. You could trivially write an interpreter that reads a file and then sends each character to a remote vim-session. If keystrokes can simply be counted as bytes, this simplifies everything without giving vim answers an unfair advantage.

• I could feed all the programs I write through an unzipping utility before running them. Zipped bytes are exactly like unzipped bytes; it's just a slightly different way of entering them. – feersum Apr 21 '16 at 18:57
• I agree that modifiers shouldn't count because G and g are both one byte. – cat Apr 21 '16 at 18:58
• @feersum Except then you have different bytes. A compressed string of bytes is different than the original string of bytes, whereas a string of bytes in a file is the same as the string of bytes than vim sees. – James Apr 21 '16 at 18:59