Writing Vim Plugins • Hacker News Board

Re: Writing Vim Plugins

#11

Post by seri » Tue, Sep 06, 2011, 3:30 PM UTC

BasDirks wrote: post #9

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.

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.

Re: Writing Vim Plugins

#12

Post by telemachos » Tue, Sep 06, 2011, 3:41 PM UTC

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...

Re: Writing Vim Plugins

#13

Post by stevelosh » Tue, Sep 06, 2011, 3:46 PM UTC

stewbrew wrote: post #5

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.

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.

Re: Writing Vim Plugins

#14

Post by stevelosh » Tue, Sep 06, 2011, 3:57 PM UTC

seri wrote: post #11

BasDirks wrote: post #9

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.

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, y…

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` I now type `:edit("foo.py")`. 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.

Re: Writing Vim Plugins

#15

Post by crazydiamond » Tue, Sep 06, 2011, 4:38 PM UTC

seri wrote: post #11

BasDirks wrote: post #9

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.

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, y…

I'd rather keep off dependencies to other languages. Recently there were issues when compiling with the ruby option -- iirc, it was required for Command-T or some other plugin. Some version of ruby was required which was not compatible with the latest stable version of vim. Something like that. Also, won't this slow down startup ? (I know lua is fast). Also, lua is not even part of any default install, to my knowledge.

Re: Writing Vim Plugins

#16

Post by BasDirks » Tue, Sep 06, 2011, 5:34 PM UTC

latortuga wrote: post #10

BasDirks wrote: post #9

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.

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.

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.

Re: Writing Vim Plugins

#17

Post by LiveTheDream » Tue, Sep 06, 2011, 7:04 PM UTC

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

Re: Writing Vim Plugins

#18

Post by gurraman » Tue, Sep 06, 2011, 10:05 PM UTC

stevelosh wrote: post #14

seri wrote: post #11

Earlier quoted context omitted.

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, y…

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…

"Small" things like adding proper support for background processes, a slightly beefier standard library and better ways to integrate plugins with the ui (a clean api instead of resorting to buffer-hacks etc) would go a long way without destroying backwards compatibility.

Re: Writing Vim Plugins

#19

Post by gurraman » Tue, Sep 06, 2011, 10:10 PM UTC

crazydiamond wrote: post #15

seri wrote: post #11

Earlier quoted context omitted.

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, y…

I'd rather keep off dependencies to other languages. Recently there were issues when compiling with the ruby option -- iirc, it was required for Command-T or some other plugin. Some version of ruby was required which was not compatible with the latest stable version of vim. Something like that. Also, won't this slow down startup ? (I know lua is fast). Also, lua is not even part of any default install, to my knowledg…

I'd do too. I didn't time it, but i am perceiving/imagining a huge difference when starting vim after recompiling without ruby- and python.

Re: Writing Vim Plugins

#20

Post by seri » Wed, Sep 07, 2011, 9:15 AM UTC

stevelosh wrote: post #14

seri wrote: post #11

Earlier quoted context omitted.

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, y…

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…

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.