
Writing Vim Plugins - stevelosh
http://stevelosh.com/blog/2011/09/writing-vim-plugins/
======
telemachos
Damian Conway wrote a five-part series on Vimscript for IBM's developerWorks.
I found it a good way to start doing more with Vimscript:

[http://www.ibm.com/developerworks/linux/library/l-vim-
script...](http://www.ibm.com/developerworks/linux/library/l-vim-
script-1/index.html)

[http://www.ibm.com/developerworks/linux/library/l-vim-
script...](http://www.ibm.com/developerworks/linux/library/l-vim-
script-2/index.html)

[http://www.ibm.com/developerworks/linux/library/l-vim-
script...](http://www.ibm.com/developerworks/linux/library/l-vim-
script-3/index.html)

[http://www.ibm.com/developerworks/linux/library/l-vim-
script...](http://www.ibm.com/developerworks/linux/library/l-vim-
script-4/index.html)

[http://www.ibm.com/developerworks/linux/library/l-vim-
script...](http://www.ibm.com/developerworks/linux/library/l-vim-
script-5/index.html)

------
crazydiamond
Thanks Steve. Not only is your post on coming back to Vim (about plugins)
excellent, but so is this. I've always wanted to write plugins but been lost.
I would then write shell scripts and then call them from Vim. Hopefully, this
will spur me to write plugins.

~~~
stevelosh
Thanks!

The easiest way to get started writing plugins is by:

* Writing little functions and mappings in your .vimrc.

* Looking at the code for a relatively small plugin someone else has made.

Give it a try! Vimscript is awful but making plugins is still fun.

~~~
aidos
Your hard work is definitely much appreciated. I switched to Vim a week ago
and Coming Home to Vim has been like a bible.

------
codito
Nice tips. I disagree on the unit test one though. I've been hacking on a
vim+python based plugin (and learning python on the way) for past few days.
When I started, I would fire vim up, test something and hit a non-actionable
error (since I won't have the entire stack trace, nor could I use
pdb.set_trace/attach debugger :().

Now I isolate vim as much as possible from core piece of code, and use a mock
vim[1][2]. For every entrypoint into my python code from vim, I write a small
unittest; run/debug it w/ nose and then just hook it to a vim key mapping. It
reduced trial/error cycles significantly. \-- [1]
[http://tadhg.com/wp/2010/02/16/some-vim-script-
implementatio...](http://tadhg.com/wp/2010/02/16/some-vim-script-
implementation-testing-and-hackery/) [2]
[http://symlink.me/repositories/entry/blogit/testing/mock_vim...](http://symlink.me/repositories/entry/blogit/testing/mock_vim.py)

~~~
oinksoft
If I recall, tlib contains testing utilities. I haven't used them myself.

<http://www.vim.org/scripts/script.php?script_id=1863>

<https://github.com/tomtom/tlib_vim>

------
tudorizer
Great tips. I'm happy to see a lot of vim related posts hitting the HN front-
page recently.

------
stewbrew
Nice article. I don't agree on the version numbering scheme though. In vim,
version numbers are major.minor. Each plugin should define a variable
g:loaded_PLUGIN_NAME that is set to the version number as integer (= 100 *
major + minor). I.e. 0.1 is 1, 1.2 is 102, 2.12 is 212. This is important for
dependency management or when users put code into after/plugin/name.vim that
patches a specific version of a plugin.

~~~
stevelosh
Why not use both?

Use semantic versioning when tagging/releasing your project so humans can
understand the version numbers.

Set your g:loaded_yourplugin variable to the integer version of the major &
minor components of the semver version number. You can ignore the bugfix
component because the dependency management stuff is likely going to only care
about which features are present.

------
BasDirks
I really like to write my plugins in Python, and Sublime Text 2 accommodates
this perfectly. With the recent addition of Vintage (vi) Mode, I find myself
using ST2 over vim more and more.

~~~
seri
Likewise. Although the API documentation for ST2 is not yet mature as the API
itself is changing, having written against ST1, I must say the experience
feels much more intuitive and modular than writing for Vim.

Pathogen is great, but I would love to see a near-complete rewrite for the Vim
ecosystem. This rewrite will inherit the bundle structure from modern editors
like Sublime Text and Textadept. Sorry Vimscript, you just have to go. And I
would pick Lua rather than Python as the interfacing language.

I'm saying all this because I still prefer using Vim to anything else.

~~~
stevelosh
As much as I hate Vimscript, I don't think changing it to something else would
work.

First, there's just a ridiculous amount of plugins and such already made.
Either they'd need to be ported to the new interface (an _insane_ amount of
work) or the old interface (Vimscript) would need to be maintained alongside
the new. Neither option seems very practical.

Second, the main advantage of Vimscript is that it uses the same commands you
use every day while working with Vim. `edit foo.py` in a Vim plugin does the
same thing as `:edit foo.py` in your daily routine. This makes it really easy
to get your feet wet with Vim scripting -- in fact it makes it all but
unavoidable.

Users learn tidbits of Vimscript while working, then start hacking stuff into
their .vimrc files, then move on to learning more and writing plugins. It's a
fairly natural progression.

If you're going to change Vimscript to something else you have a couple of
options, all of which suck:

* Replace Vimscript in the daily routines with Lua/whatever. Instead of typing `:e foo.py<cr>` I now type `:edit("foo.py")<cr>`. No way this would ever work with Vim's community.

* Keep using Vimscript for daily commands, but use Lua when reading from files. This loses the main advantage of Vimscript (which I think is a really important one), plus you now need to maintain two interfaces.

~~~
seri
First of all, I should state more clearly that I am describing my view of a
_dream editor_ rather than what I think should be done right in the Vim
community. That editor will keep the core functionality of Vim, and probably
the core code base, but it will have to rewrite the interface from scratch,
with Lua being chosen as the only embedding language.

I am not too unhappy with the current situation by any means, but it's
precisely because I have a biased relationship with Vim that I feel uneasy
seeing how civilized it is to write extensions for other editors.

That said, while my dream editor probably won't be Vim 8.0, it may be in the
form of a brand new fork. I do think that sounds practical.

About your first concern, historically speaking, programmers as a community
don't seem to mind porting things from one platform to another. It's actually
quite a fun thing to do, especially if the new platform is polishedly
designed.

Your second point is interesting. I admit it's something I haven't thought of
and only sounds obvious now that you say it. I would say my dream editor will
have to sacrifice the command mode altogether. If there is something you type
in the command mode very often, you write it as a Lua function and bind to a
key.

------
LiveTheDream
The scrolling header is a very nice touch on this article.

