5 ms·

Writing Vim Plugins

253 points by stevelosh 15y ago

crazydiamond 15y ago
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 15y ago
  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 15y ago
    Your hard work is definitely much appreciated. I switched to Vim a week ago and Coming Home to Vim has been like a bible.
tudorizer 15y ago
Great tips. I'm happy to see a lot of vim related posts hitting the HN front-page recently.
stewbrew 15y ago
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 15y ago
  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.
codito 15y ago
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-implementation-testing-and-hackery/ http://tadhg.com/wp/2010/02/16/some-vim-script-implementatio... [2] http://symlink.me/repositories/entry/blogit/testing/mock_vim.py http://symlink.me/repositories/entry/blogit/testing/mock_vim...
- oinksoft 15y ago
  If I recall, tlib contains testing utilities. I haven't used them myself. http://www.vim.org/scripts/script.php?script_id=1863 http://www.vim.org/scripts/script.php?script_id=1863 https://github.com/tomtom/tlib_vim https://github.com/tomtom/tlib_vim
BasDirks 15y ago
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.
- latortuga 15y ago
  Maybe this is obvious but you can write vim plugins in python, end user vim simply must be compiled with python support. On my laptop running ubuntu, vim came with ruby and python support by default.
  - BasDirks 15y ago
    I do realize this, but the heads up is appreciated. In ST2 everything just fits so neatly together, and the (very nice) API is geared towards Python scripts.
- seri 15y ago
  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 15y ago
    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.
telemachos 15y ago
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-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 http://www.ibm.com/developerworks/linux/library/l-vim-script...
LiveTheDream 15y ago
The scrolling header is a very nice touch on this article.

253 points by stevelosh 15y ago

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 15y ago
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 15y ago
  Your hard work is definitely much appreciated. I switched to Vim a week ago and Coming Home to Vim has been like a bible.

tudorizer 15y ago

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

stewbrew 15y ago

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 15y ago
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.

codito 15y ago

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-implementation-testing-and-hackery/ http://tadhg.com/wp/2010/02/16/some-vim-script-implementatio... [2] http://symlink.me/repositories/entry/blogit/testing/mock_vim.py http://symlink.me/repositories/entry/blogit/testing/mock_vim...

oinksoft 15y ago
If I recall, tlib contains testing utilities. I haven't used them myself. http://www.vim.org/scripts/script.php?script_id=1863 http://www.vim.org/scripts/script.php?script_id=1863 https://github.com/tomtom/tlib_vim https://github.com/tomtom/tlib_vim

BasDirks 15y ago

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.

latortuga 15y ago
Maybe this is obvious but you can write vim plugins in python, end user vim simply must be compiled with python support. On my laptop running ubuntu, vim came with ruby and python support by default.
- BasDirks 15y ago
  I do realize this, but the heads up is appreciated. In ST2 everything just fits so neatly together, and the (very nice) API is geared towards Python scripts.
seri 15y ago
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 15y ago
  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.

telemachos 15y ago

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-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 http://www.ibm.com/developerworks/linux/library/l-vim-script...

LiveTheDream 15y ago

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