Writing Vim Plugins
stevelosh.com
stevelosh.com
http://www.ibm.com/developerworks/linux/library/l-vim-script...
http://www.ibm.com/developerworks/linux/library/l-vim-script...
http://www.ibm.com/developerworks/linux/library/l-vim-script...
http://www.ibm.com/developerworks/linux/library/l-vim-script...
http://www.ibm.com/developerworks/linux/library/l-vim-script...
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.
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... [2] http://symlink.me/repositories/entry/blogit/testing/mock_vim...
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.
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.
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.
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.
"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."
As of now, www.vim.org contains 3,716 scripts. It would be a tremendous amount of work to rewrite them all. However, that would not be necessary. First of all, the vast majority of scripts on vim.org are abandoned after a version or two, and never get very many users (if any). Second, many scripts on vim.org are for outdated versions of vim (usually 6.x), and don't work on the newer (7.x) versions of vim anyway. They are also effectively abandoned. So they don't need to be rewritten either. Really, the important scripts that would need to be rewritten are the really popular ones, and there just aren't that many of them. It might be a fair amount of work, but not overwhelming.
"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."
It's true that there are some similarities between vimscript and the regular commands you'd use in ordinary vim editing, but there are also many differences -- such as functions, looping constructs, conditionals, lists and dictionaries, etc. I don't think losing the ability to use vim editing commands in scripting vim would really be a particularly big deal for most vim users, as most of them probably already know another scripting language anyway.
Finally, there's actually no reason to get rid of vimscript altogether. It would hurt no one if it remained an option for scripting vim. What does need to happen, however, is that more of vim needs to be opened up to being scripted from other languages. The existing language bindings are often pretty crippled compared to vimscript, and you often need to call vimscript from within those other languages to do everything you need, making the use of another language a superfluous waste of time. So what really needs to happen is to fully get rid of the dependency on vimscript, not to get rid of vimscript itself.