Tips for golfing in V

4

What general tips do you have for golfing in V? I'm looking for ideas which can be applied to code-golf problems and which are also at least somewhat specific to V (e.g. "remove comments" is not an answer).

Since V is heavily based on vim, most of the tips for golfing vim would apply too. But there are some features in V that don't really apply to vim.

Please post one tip per answer.

James

Posted 2017-06-04T23:56:28.157

Reputation: 54 537

Answers

3

Take advantage of implicit endings!

In V, every single command will be implicitly finished if you don't actually finish out the command. For example, if the program ends in insert mode, the <esc> will be filled in automatically. Usually, this doesn't make any difference. However, if you have a count before the i, you have to actually hit <esc> at the end for the text to be inserted multiple times. So you can do 2i2i for a quine, whereas in vim you would need 2i2i<esc>, which is no longer a quine.

This also applies to ex commands, and psuedo ex-commands such as compressed regexes. So where vim needs

:foo<cr>

V can do

:foo

if it's at the end of the program.

But here is where it gets really cool: The implicit ending applies several layers deep. For example, consider this command:

òçfoo/óa

This translates to:

ò           " Recursively:
 çfoo/      "   On every line matching 'foo'
      óa    "     Remove the first 'a'

Without implicit endings, the ó needs a <cr>, the ç needs a <cr>, and the ò needs another ò. But none of these are needed with implicit endings! The interpreter will fill in the needed ò, the recursive command will fill in the <cr> that ç needs, and the ç command will fill in the <cr> that ó needs. This saves us 3 bytes.

James

Posted 2017-06-04T23:56:28.157

Reputation: 54 537

3

Carefully choose how you take input.

V can take input two different ways: input and args. It can even take both at the same time! Choosing how you take input can sometimes save you many bytes. Here is how the two input formats work:

  • The input is the text that is loaded into the buffer. Generally, this is more convenient for string inputs.

  • The args are stuffed into the first n registers, depending on how many args are given. For example, if 5 args are given, these will be loaded into registers a-e. Since you can run these registers with @<reg>, these are generally more convenient for numeric input.

Lets make a hypothetical example. Our hypothetical challenge is:

Given a string s, and an integer n, output s n times, separated by a newline.

In vim, you can only take input into the buffer. So you'd need to take the input on two lines, for example

n
s

And run

DJY@-pdd

The D to delete n into register '-', the J to remove the extra newline, and then @-p to paste s n times, and dd to take care of the extra copy. In V, you can take s as input, and n as an arg. Then you could shorten this too:

@apdd

of course, there's still a few ways to shorten this even more. For example, Ä makes n copies, rather than pasting n times. And À, or <M-@> will cycle through all of these args, so the first time it's called it is equivalent to @a. So you can simply do:

ÀÄ

The À will command will also loop back once you go through all of the args. So if you have 3 arguments, running À repeatedly will run

@a
@b
@c
@a
@b
@c
@a
...

James

Posted 2017-06-04T23:56:28.157

Reputation: 54 537

And what happens when you go over @z? – Erik the Outgolfer – 2017-06-15T09:28:58.520

@erikthegolfer I don't know. I've never used that many args. – James – 2017-06-15T14:31:10.927

what unprintable put that in my inbox? – Erik the Outgolfer – 2017-06-15T14:33:29.137