# Is "vim + plugins" a valid language?

It is probably not a shock to most of you, but I really enjoy answering code golf questions in Vim. There are many vim plugins that could greatly shorten some answers. For example, surround, subvert, easymotion, and many others could potentially save many bytes on the right challenge.

I've been wondering whether it would/should be allowed for a while, and it seems like the current consensus is contradictory. For example, as Mego wrote in this answer (+14/-0 right now):

Using a third-party library/module/extension/whatever has always been allowed by default. It should be noted in the answer that it is not the "vanilla" language (something like Language + Library/Libraries is the most common way).

...

What you do get for free is the assumption that a certain third-party library (or set of third-party libraries) is present on the machine, and can be used via the normal mechanisms of the language.

This seems to imply that adding plugins is fine, and should cost no penalty. However as I myself wrote in this answer (+12/-0 right now):

On PPCG, languages are defined by their implementation. This includes any configuration files. Therefore, if you edit your local configuration files, you are essentially creating a new unpublished implementation of an existing language.

...

Presumably any language that might benefit from tweaking defaults would also have a way to edit that behavior inside of your solution, and however many bytes of boilerplate that takes is a reasonable byte handicap.

Here is where the problem arises. In Vim, the only way to install a plugin is to edit your .vimrc to source the relevant files. Although you could manually source them, this feels very weird because a) it's not the traditional way of installing a plugin, b) vim submissions rarely need to use much vimscript, which sourcing plugins is entirely vimscript, and c) sourcing plugins is so verbose, solutions manually doing this will never be competitive.

So this brings up several questions.

• Can plugins be installed for vim answers?

• If so, can they be installed the normal way, by editing the .vimrc or must they be manually sourced? If they can be installed the normal way, is there any byte penalty for using them?

• An interpreter could switch out the .vimrc file, launch VIM and then swap it back. Mar 12, 2017 at 20:49
• Yes, unless the plugin turns it into Javascript or something :P Mar 13, 2017 at 17:15

Yes, it's valid in the same way that Python + NumPy (for example) is valid. Changing the .vimrc configuration file isn't much different logically from installing a Python package (which is mostly just putting the package's files in /usr/lib/python/site-packages, or whatever the path is for the system). The method of installation isn't the concern here - it's the presence or absence of functionality created by a third party that is not part of the standard installation of the language.

• I assume that this only applies to plugins demonstrably written before the challenge?
– Liam
Mar 19, 2017 at 14:03
• @Liam Well, of course
– cat
Mar 22, 2017 at 12:36

Yes, and Mego's answer details all the reasons why, but you should have to include the changes to the .vimrc file in the bytecount, in the same way you have to count import statements.

• I like this idea. You shouldn't be able to import for free. Mar 20, 2017 at 20:55
• I disagree with this; It's easy to write a wrapper for a language to snuff out the import penalty, but it's not exactly possible to do that in VIM. I think it should be free. Mar 21, 2017 at 2:17