7

In one of the vim plugins I use, we have been thinking about using python vs vimscript going forward (https://github.com/python-mode/python-mode/issues/813#issuecomment-344754563).

I understand that you can use Python to write plugins for VIM (https://dzone.com/articles/how-write-vim-plugins-python) as long as you have a +python/+python3 in your vim distribution, the plugin should work.

I haven't written any plugins for VIM, but I think writing an opensource VIM plugin for Python development in Python is better compared to writing it in VimL. You will notice that there are multiple users who suggested solutions, but don’t know VimL, and don’t want to learn it, because they already know Python and are working in Python. Thus writing new code in Python going forward will enable us to get more users as well as get more contributors and create more value.

Question

What are the drawbacks of writing a Vim plugin using Python vs VimL? (Let's assume that all users who use this plugin already has +python/+python3, because they are going to be using it to develop Python)

  • 6
    If you choose python, please use python3. vim cannot reliably use both python2 and python3 plugins at the same time and increasingly distributions no longer ship with python2 and/or a version of vim compiled with python2 support, causing a few plugins to break (even for python users). – Mass Dec 20 '17 at 4:21
  • @Mass, thanks for the feedback.. I agree.. most people probably have moved over to python3. Also I dont think we have enough resources to support both python3 and python2.. – alpha_989 Dec 25 '17 at 15:30
9

TL;DR:

Requiring +python/+python3 support for a python based development plugin. That sounds completely reasonable.

About Vim plugins and human behavior

Generally, speaking humans want things to appear simple and "just work". When it comes to Vim plugins, Vimmers typically want plugins with no or very few dependencies. Basically it should be as simple as a git clone and/or a few lines in their vimrc file. The more a plugin requires to be configured in order to work initially or requires some dependency is just adding a barrier to entry.

A great example of this behavior is CommandT vs CtrlP:

  • CommandT uses Ruby and C to accomplish fuzzy finding
  • CtrlP on the other hand is pure VimL/Vimscript
  • CommandT is typically faster than vanilla CtrlP

Now you would assume CommandT to be more popular especially since it came out first, but that is not the case. CommandT has approximately 2000 users and CtrlP has approximately 20,000 users. In my opinion CommandT's requirements cause a barrier to entry. You simply cannot git clone your vim dotfiles and be up and running on a new machine with CommandT like you can with CtrlP.

Counterpoint:

That is C + Ruby not +python/+python3. There is built in support for Python. You are absolutely correct. An example that proves this point would be Gundo (~5,000) using +python vs undotree (~1,000) which is pure VimL. I would argue, in my personal opinion, that undotree is less well known than Gundo (first to market) and the fact that many are using undotree may very well have to do with it being pure VimL vs python.

Good enough for me, I will just use Python for my Vim plugin!

At the end of the day you have to know quite a bit about Vim and some VimL to do Vim plugin in Python. The vim module is much better than it was before, but still requires a fair amount of VimL eval-like situations:

vim.command("set tw=72")
vim.command("%s/aaa/bbb/g")
text_width = vim.eval("&tw")

See :h python-vim.

You will also need VimL to "bootstrap" the python portion of you plugin. So there is no escaping VimL, just reducing the amount.

Conclusions

If you have a need for +python/+python3 then certainly use it. It sounds like you have a wonderful use case for python support. However in my opinion you will not completely escape VimL/Vimscript. I would recommend doing Vim things in VimL and use python for thing that are hard/tricky/slow to do in VimL.

  • Thanks for the detailed write-up and showing the examples. I didn’t have these examples, and it kindof verifies my intuition. – alpha_989 Dec 25 '17 at 16:11
  • To your point about making the installation as simple as possible, I agree with you, and we discussed this. There could be some benefits from using git submodule from the point of development, but perhaps we have to encapsulate that in a bash script, so people don’t have to go through too much hurdles to be able to install this plugin. That way we could address the concerns of the developers and users. – alpha_989 Dec 25 '17 at 16:12
  • This could take some time, so in the near term a simpler solution would be to just have an alternate link to an older stable version of the python-mode plugin (would have some more bugs compared to the current version) which can be directly installed by including a line in the vimrc, or by git clone. – alpha_989 Dec 25 '17 at 16:12
  • I also had the same feeling about going down the python route, that it could be a barrier to entry. The reason I thought it might be ok to use +python3, is because most people probably use a “huge” version which comes installed with python. Further, the current python-mode by default already requires +python3 and +python by default, so current users are not going to have to change versions of vim. – alpha_989 Dec 25 '17 at 16:13
  • Also, thanks for the tips about python-vim, I will read up on that. I was trying to minimize VimL usage, not necessarily eliminate it. If we have a goal of writing as much as possible in python (but not everything), then as python implementation in VIM improves, my thought was that we can probably start converting more of the codebase into python. – alpha_989 Dec 25 '17 at 16:14
2

Speaking for myself, mostly in Windows but sometimes other platforms, I've never been satisfied by the reality of the Python integration. I appreciate that it's there for the folks that need it but it doesn't "just work;" you've got to get the precise version of the Python DLL and it was trial and error for me when I last did it and ultimately I found that the payoff wasn't worth the effort.

Today, I have some functionality that I wrote in Python that I use inside of Vim and I trigger it with a system('python ...') call to execute the script.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.