percentage of vim users running python
Ted
I'm wondering if there are some figures somewhere that would provide
some sort of estimate of the percentage of vim users who have python
installed, or would be free of objections to installing it if a module
required it. I'm working on some vim modules, to be released for
general use, that are threatening to become pretty complicated, and
would prefer to write them in python. Is it likely that this would
lock out a significant portion of the vim user population? Is it
frowned upon to use external languages in cases where it's not
entirely necessary? Python is more or less ubiquitous on linux
installs, but I don't feel like I could guess at how many vim users on
other platforms would be unable or unwilling to install it.
The modules themselves are relatively general purpose; my motivation
to code them in Python stems partly from this very generality: it's
advantageous to have that code available outside of the context of
vim. I also find that I tend more and more toward a functional
programming style that doesn't work particularly well in vimscript.
Cheers
-Ted
AK
system? If I understand right, windown installer for Vim comes with
python compiled into Vim. Same goes for Vim in Ubuntu. On other
distributions, I'm not sure, I believe I heard that Redhat's Vim does
not have Python compiled in.
If you're using python from Vim, it might make sense to use compiled in
interpreter because there's closer integration with Vim rather than
outside interpreter. If you haven't done this already, read :help python.
-ak
--
Python plugins for vim: outliner, todo list, project manager, calendar,
expenses tracker, sortable table, and more |
http://lightbird.net/pysuite/
George V. Reilly
> On 06/29/2010 09:20 PM, Ted wrote:
> > I'm wondering if there are some figures somewhere that would provide
> > some sort of estimate of the percentage of vim users who have python
> > installed, or would be free of objections to installing it if a module
> > required it. I'm working on some vim modules, to be released for
> > general use, that are threatening to become pretty complicated, and
> > would prefer to write them in python. Is it likely that this would
> > lock out a significant portion of the vim user population? Is it
> > frowned upon to use external languages in cases where it's not
> > entirely necessary? Python is more or less ubiquitous on linux
> > installs, but I don't feel like I could guess at how many vim users on
> > other platforms would be unable or unwilling to install it.
> >
> > The modules themselves are relatively general purpose; my motivation
> > to code them in Python stems partly from this very generality: it's
> > advantageous to have that code available outside of the context of
> > vim. I also find that I tend more and more toward a functional
> > programming style that doesn't work particularly well in vimscript.
>
> system? If I understand right, windown installer for Vim comes with
> python compiled into Vim. Same goes for Vim in Ubuntu. On other
> distributions, I'm not sure, I believe I heard that Redhat's Vim does
> not have Python compiled in.
>
> If you're using python from Vim, it might make sense to use compiled in
> interpreter because there's closer integration with Vim rather than
> outside interpreter. If you haven't done this already, read :help python.
The Windows build refers to a Python DLL and will load it if it can find
it. However, Python itself is not included with Windows Vim and must be
separately installed. It must also be the same version of Python (e.g.,
python26.dll) and the DLL must be in the search path, :h python-dynamic
The average Vim user on Windows is, I suppose, somewhat likely to already
have Python, and, if not, will likely be amenable to installing it
-- especially if it gets them some useful Vim extensions.
But this is all supposition; I know of no way to get meaningful numbers on this.
--
/George V. Reilly geo...@reilly.org Twitter: @georgevreilly
http://www.georgevreilly.com/blog http://blogs.cozi.com/tech
sc
> I'm wondering if there are some figures somewhere that would
> provide some sort of estimate of the percentage of vim users
> who have python installed, or would be free of objections to
> installing it if a module required it. I'm working on some
> vim modules, to be released for general use, that are
> threatening to become pretty complicated, and would prefer to
> write them in python. Is it likely that this would lock out
> a significant portion of the vim user population? Is it
> frowned upon to use external languages in cases where it's
> not entirely necessary? Python is more or less ubiquitous on
> linux installs, but I don't feel like I could guess at how
> many vim users on other platforms would be unable or
> unwilling to install it.
i'd like to count myself among those who like a lean build
with no extra languages compiled in and as few plugins running
as possible
whatever your modules do i would not consider them if they
require a python enabled vim
sc
bill lam
want it, they will not mind installing python. I personally aren't a
fans of python and will not bother to use vim with python albeit
python is installed here in linux.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Christian Brabandt
> i'd like to count myself among those who like a lean build
> with no extra languages compiled in and as few plugins running
> as possible
>
> whatever your modules do i would not consider them if they
> require a python enabled vim
Same is true for me. On windows, I don't even have Python installed
and wouldn't bother to install it just for a plugin. (Though, I'd like
to try out command-t[1], but even for that, I wouldn't install Ruby).
And on linux, it depends what build of vim I am using. Not all versions
are build with python/ruby/perl support and I usually can't rely on
having any interpreter available.
[1] http://www.vim.org/scripts/script.php?script_id=3025
regards,
Christian
Marko Mahnič
> Hello folks,
>
> I'm wondering if there are some figures somewhere that would provide
> some sort of estimate of the percentage of vim users who have python
> installed, or would be free of objections to installing it if a module
> required it.
some of the plugins that already use +python:
vimpdb http://www.vim.org/scripts/script.php?script_id=2043
postmail http://www.vim.org/scripts/script.php?script_id=2341
pysmell http://www.vim.org/scripts/script.php?script_id=2421
pyflakes http://www.vim.org/scripts/script.php?script_id=2441
vimuiex http://www.vim.org/scripts/script.php?script_id=2606
utilsnips http://www.vim.org/scripts/script.php?script_id=2715
conque http://www.vim.org/scripts/script.php?script_id=2771
Marko
Marc Weber
Go for Python because VimL can be a lock-in (speed issues if you want to
do a lot).
Can you tell more about what you're going to implement?
Maybe you want to get some ideas from my sbt plugin:
www.github.com/MarcWeber/vim-addon-sbt
It mocks Vim functionality so that you can test it without Vim and use a
Python debugger etc. It also illustrates how to load an external .py
file (syntax highlighting, etc will be better then). Probably you
already know..
> vim. I also find that I tend more and more toward a functional
> programming style that doesn't work particularly well in vimscript.
:-). Vim does neither support Scala, F# nor Haskell. Maybe you should be
using lisp or scheme then.
Marc Weber
Matthew Winn
wrote:
> Go for Python because VimL can be a lock-in (speed issues if you want to
> do a lot).
Isn't it rather the opposite? If something requires Python it's at the
mercy of the availability of Python and the ability of Vim to make use
of the available Python if the language is installed, while something
in native Vim will run anywhere.
I remain unconvinced of the utility of the additional languages for
anything other than personal use. Even when they are available the
linking may require a particular version, and that version may not be
the same as the version needed by other applications.
I can't remember the last time I saw a machine with Python installed
in a generally available form, and that machine only had it because
I put it there. (I've seen a few with it installed privately for one
specific application, but that's not terribly useful.) It's far from
ubiquitous, and very few people are going to go to the trouble of
installing a new language just to use a plugin.
--
Matthew Winn
Ted
demographic is a bit more restricted than the general population of
vim users; it is that portion thereof who actually install vim modules
at all. It's informative to learn that there are some in that group
who would not be willing to install python as a module dependency.
At the risk of straying off-topic: is there a consensus on the correct
term for a "vim script"? That phrase itself seems too specific, and
too easily conflated with one of the files contained in such a
package, or any file with the `.vim` extension. I tend to call them
"modules", coming from Drupal and Python; Marc here seems to prefer
the term "addon"; is there a standard term that should be used to
avoid confusion?
Marc's response gave me the most food for thought, so I am going to
reply to his questions and observations, but much of this applies in a
general context (thus the reply to all response).
On Jun 30, 5:34 am, Marc Weber <marco-owe...@gmx.de> wrote:
> Go for Python because VimL can be a lock-in (speed issues if you want to
> do a lot).
is with any code that's not closely tied to vim's functionality. I
guess I'm wondering if it's expected, or at least recommended, that
general-purpose routines be re-implemented in VimL rather than being
made available through dependencies on other languages.
I've written (in addition to the code that prompted my question)
some -- decidedly low-rent -- URL parsing code; this is another
example of something that is definitely readily available in other
languages that vim has bindings for. Without regular additions to the
VimL "standard library", ie the set of autoloads and plugins that come
installed in $VIMRUNTIME, there ends up being a lot of potential code
that is in this ambiguous area. The absence of a widely used system
of dependency management [1] means that much of this code may need to
be, or has already been, implemented on a module-by-module basis.
This is the alternative to having the typical user manually install 6
different modules in order to get something working, or perhaps
instead decide that the thing requires far too much effort. Which in
turn means that, especially as vim modules become more powerful, there
will end up being a lot of redundant code loaded into memory. Or
underused scripts.
1: at least to my knowledge; Marc, I am aware of your vim-addon-
manager plugin. It sounds pretty useful and is one of those things
that I haven't had time to try out and hopefully start using
regularly. But it seems like it's not yet widely used, and I would
hesitate before taking advantage of its presence by splitting a
comprehensive vim module into a set of interdependent components.
It's again a question of how open the average user (of addons) is to
integrating higher-level tools in order to satisfy their immediate
goals.
> Maybe you want to get some ideas from my sbt plugin:www.github.com/MarcWeber/vim-addon-sbt
>
> It mocks Vim functionality so that you can test it without Vim and use a
looks like you're just implementing the stuff you need to test that
script.. is there a more general purpose vim "test double" Python
module somewhere? In addition to various other projects, I've also
got a fledgeling drop-in replacement for the `vim` module on the go,
after I didn't find anything with some Googles.
> Can you tell more about what you're going to implement?
when I wrote the original post. The project in question is basically
a set of routines for manipulating an outlining/markup file format
that I sort of .. accidentally evolved over the past couple of years.
The format itself is still fairly nebulous so I don't expect anything
to be releasable any time soon. I've not needed anything really high-
level so far, but I'm getting to the point where it's going to start
saving me time and confusion to have something more complex built.
The format is basically syntactic sugar on XML (err, I guess the XML
is "on sugar"?), so it could be appealing to eventually be able to use
Python's DOM classes to work with it, and in the meantime it would be
more convenient to do a lot of the off-the-cuff text processing in
Python.
For example, I use this format for taking notes, and one of the things
that I commonly do is to paste in a quotation from a browser, split it
into sentences, and make each of those sentences a "quoted" node,
which is just a line which at the right indentation level that
contains a double-quote character and a space followed by the
sentence. There are a few subroutines inherent to this procedure, and
the sentence-splitting in particular is something that could be very
context-dependent, with a varying degree of generality: for example,
in some cases I want to split out the elements of a list of items,
delimited by commas or words like "and" or "or", rather than splitting
on sentence boundaries. In other cases I need to specify that the
text is already in point form. In Python I would make the basic
sentence splitting subroutine the default value of a parameter, and
then just override it with a different function, or maybe use a class
if it started getting really complex.
Although this is doable in VimL, I think it's necessarily a bit ugly,
and I would perhaps face censure from would-be contributors if I were
to, for example, write a closure by execing a string that contains an
anonymous function definition. That being said, VimL is not
particularly similar to Python, so perhaps there are better models to
be applied than that of Python. If there is a comprehensive coding
style guide somewhere, please point me to it; I see a lot of
possibilities, especially with respect to copy-prototypal inheritance,
but few signs pointing to existing conventions or common techniques.
The lack of development in this direction could suggest that people
are still tending to do complicated things in bound languages (Python,
perl, etc.), or perhaps external tools (though this would seem to be
more of a portability issue than most languages). Or it may perhaps
just indicate a desire to prevent vim from expanding into an operating
system lacking a decent editor.
I'm currently experimenting with making the top-level function a
dictionary function, and using the dictionary as I would, in Python,
use keyword arguments. To this end I wrote some code to make it
convenient to copy the prototype dictionary that contains the function
and its defaults, while applying options, and then call the function.
It ends up using method chaining and being somewhat Javascript-ey. I
called it "Merger": it has Ours (keeps defaults), Theirs (overrides
defaults), and Safe (throws exceptions on conflict) methods, as well
as recursive versions of said methods, which deepcopy the original and
merge in their dictionary parameter, then return the result. There
are also some methods like Apply and Call that make it easier to call
dictionary or non-dictionary functions on the object. It appeared to
me that, although not particularly complex (I think the whole thing is
about 40 lines), it should really go into some kind of general-purpose
library or into a separate module.
I remembered that I had a few of those in my list of things that might
be useful later on, and I should probably scan through them to see if
this sort of thing is implemented in any of them. But they seem
pretty time-consuming to go through, and I was a bit worried that the
procedure might, at this point, cause my brain to have some sort of
stack overflow error from yet another level of sub-task. I also
thought that if this module that I'm building is going to depend on a
separate utility module, and at this rate likely 6 or 10 others, how
much more of a portability issue is it going to be to just write the
whole thing in Python in the first place? And thus my question.
> :-). Vim does neither support Scala, F# nor Haskell. Maybe you should be
> using lisp or scheme then.
of lisp. Actually my use of the term "functional programming" should
probably be taken with a grain of salt; my experience in this respect
is mostly limited to what's possible in Python through the
`itertools`, `functools`, and `functional` modules, and through the
use of closures. But I like what I've learned of it so far.
Marc Weber
You're writing code for a system you've been using. You say its not
ready for release. Still you care much about portability and other users
(?). One design goal should be : Never over engineer. Do what you have
to do because things are going to change anyway.
Such a change could be a team mate popping up who loves Emacs.
If you have a Python module he can hack the module and Emacs and reuse
your code. If you use VimL ..
Same applies if you want to offer the functionality in web application
or whatsoever.
About plugin / addon / extension? I didn't care much. I just tried to
get the job done.
Have a look from a historical point of view: VimL was great when it was
invented. That time it was ahead of the time by years. There was no
Python or X which could be used instead. However today those languages
exist. VimL can get jobs done. However its only used within Vim.
You can use Python. However the language bindings are rather limited. Eg
Vim module doesn't provide a call function which allows you to call vim
function without caring about quoting.. Nevertheless you can hack this
up fast.
When should you use VimL?
- you're going to use many Vim commands (regex, cursor movements etc)
When should you be using Python or something else?
- you're going to implement heavy stuff such as language parsers.
You want to operate on syntax trees etc.
Sometimes a solution which only gets done 90% can be implemented *much*
faster in Vim using commands you already know. So if you task is about
finding paragraphs and adding characters or joining those paragraphs
probably I'd try to get up a quick and dirty Vim script
Do whatever you feel most comfortable with.
Python:
AK
> Thanks to all for providing input on my question. I realized that the
> demographic is a bit more restricted than the general population of
> vim users; it is that portion thereof who actually install vim modules
> at all. It's informative to learn that there are some in that group
> who would not be willing to install python as a module dependency.
there's a very large number of Python developers who use Vim but don't
know VimL or only know a little bit of it. On top of that, Python is a
very clean, powerful language with extensive libraries.
I think it's a chicken and an egg problem, once there's a large number
of good plugins, more people will choose to install python with Vim and
this will lead to more good plugins. -ak
Tony Mechelynck
Myself, I have Python installed "just in case", and even compiled into
Vim, but in practice I don't use it, in part because I don't know
Python, in part because, to extend or customize Vim, vimscript is good
enough for me. If I found a good useful script written in Vim + Python I
would not necessarily shun it as others have said they would; but so far
all my third- (and second- ;-) ) -party scripts are in "plain" vimscript.
About terminology: I think it isn't cast in bronze, but personally I use
"a Vim script" in two words to mean "a file to be sourced by Vim", or
"vimscript" in one word to mean "the programming language used to write
Vim scripts".
My main use (AFAIK) for the Python interpreter is to run Mercurial ;-)
Best regards,
Tony.
--
The fact that it works is immaterial.
-- L. Ogborn
Ted
My point of confusion with the term "a vim script" is that, in
addition to bearing a similarity to the "vimscript" or "VimL"
programming language, this can imply either of two other things:
- a package, downloadable from "http://vim.org/scripts/script.php?
script_id=$some_number", which provides new functionality for or
ameliorates existing functionality of the `vim` editor
- an individual file to be installed, as part of such a package, to,
for example, 'plugin/vigour.vim'.
My question was just if there is a preference or consensus on what
instances of the second of those two types of things should be called.
The term "plugin" is particularly confusing in this sense, as it is
the name of one of the directories into which *.vim files are
installed, and thereby indicates a subclass of *.vim file, as
differentiated from an autoload or filetype-plugin file.
It seems like Python is mostly used for more complex modules that, as
Marc mentions, do "heavy lifting", such as the conque module linked to
in Marko's list, or the very useful DBGp debugger module (http://
www.vim.org/scripts/script.php?script_id=1152). As well, there are
numerous modules that are to be used for python development (again see
Marko's list), where it's pretty safe to assume that the Python
dependency is met.
VimL/vimscript as a language is, I've found, not entirely terrible,
and is fairly well suited to scripting vim. The worst of the fallout
from its storied history would seem to be an inconsistency to nearly
rival that of PHP. But it does lack portability, a large, organized,
and growing library, module dependency management, and a lot of the
convenience factors that are readily available in Python. For
example, being able to use Python's shlex module, or even argparse, to
parse user-defined command invocations can be very useful.
So I'd really like to be able to just use Python as a general rule
when writing vim modules, even simple ones, and eventually find a way
to streamline this sort of thing. But since about half of the people
who responded to my question indicated some objection to running a
python-enabled vim, this seems like an inconsiderate policy. This
assumes that the sampling of people who did raise objections to the
use of Python have a tendency to use third-party vim modules under the
same set of circumstances in which `has('python') == 0`. Presumably
they wouldn't have responded if that weren't the case.
Cheers
-Ted
On Jul 7, 7:33 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
Nico
> I'm wondering if there are some figures somewhere that would provide
> some sort of estimate of the percentage of vim users who have python
> installed, or would be free of objections to installing it if a module
If I had to make a completely wild guess on python support, I'd say
maybe 50% of Vim script users have python-enabled Vim, and another 25%
could very easily install it. If your plugin is significantly better
using python I'd say go ahead and use it. However VimL isn't half bad,
and will probably have everything you need. So in that case it may be
silly to endanger 50% of your audience due to your personal language
preference.
Python has a few strong advantages, beyond the great standard
libraries. One of the reasons I moved Conque from VimL to python was
the very poor performance of VimL when writing to a buffer. This seems
counter intuitive, but for some reason the python buffer variable is
almost 10 times faster at updating a buffer than the builtin VimL
functions getline()/setline(). So if your plugin has to write large
amounts of content to a buffer, this would be something to take into
consideration.
A sample script to show what I mean:
"
---------------------------------------------------------------------------
" profile results
-------------------------------------------------------
FUNCTION ScreenWriteBenchPy()
Called 1 time
Total time: 2.697767
Self time: 2.697767
count total (s) self (s)
1 2.697753 python SWB()
FUNCTION ScreenWriteBench()
Called 1 time
Total time: 20.614985
Self time: 20.614985
count total (s) self (s)
501 0.003105 for k in range(1, 500)
500 0.054599 normal ggdG
50500 0.301234 for j in range(1, 100)
550000 3.337009 for i in range(1,10)
500000 7.288676 call setline(i,
getline(i) . i . j)
500000 2.684931 endfor
50000 0.228279 endfor
500 0.002241 endfor
"
---------------------------------------------------------------------------
" test.vim
---------------------------------------------------------------
function! ScreenWriteBench()
for k in range(1, 500)
normal ggdG
for j in range(1, 100)
for i in range(1,10)
call setline(i, getline(i) . i . j)
endfor
endfor
endfor
endfunction
function! ScreenWriteBenchPy()
python SWB()
endfunction
python << EOF
import vim
def SWB():
for k in range(1, 501):
del vim.current.buffer[0:10]
for j in range(1, 101):
for i in range(1,11):
if len(vim.current.buffer) < i:
vim.current.buffer.append('')
vim.current.buffer[i-1] += str(i) + str(j)
EOF