Loading ...
Sorry, an error occurred while loading the content.
 

percentage of vim users running python

Expand Messages
  • Ted
    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
    Message 1 of 15 , Jun 29, 2010
      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. 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

      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • AK
      ... Do you mean Vim compiled with python or just python installed on the system? If I understand right, windown installer for Vim comes with python compiled
      Message 2 of 15 , Jun 29, 2010
        On 06/29/2010 09:20 PM, Ted wrote:
        > 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.  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
        >


        Do you mean Vim compiled with python or just python installed on the
        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/


        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • George V. Reilly
        ... 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
        Message 3 of 15 , Jun 29, 2010
          On Tue, Jun 29, 2010 at 6:32 PM, AK <andrei.avk@...> wrote:
          > 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.
          >
          > Do you mean Vim compiled with python or just python installed on the
          > 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  george@...  Twitter: @georgevreilly
          http://www.georgevreilly.com/blog  http://blogs.cozi.com/tech

          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • sc
          ... 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
          Message 4 of 15 , Jun 29, 2010
            On Tuesday 29 June 2010 20:20:27 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.

            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

            --
            You received this message from the "vim_use" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • bill lam
            I think you need just release your utility program, if people really want it, they will not mind installing python. I personally aren t a fans of python and
            Message 5 of 15 , Jun 29, 2010
              I think you need just release your utility program, if people really
              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

              --
              You received this message from the "vim_use" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Christian Brabandt
              ... 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
              Message 6 of 15 , Jun 29, 2010
                On Wed, June 30, 2010 6:05 am, sc wrote:
                > 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

                --
                You received this message from the "vim_use" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • Marko Mahnič
                ... Maybe you could make an estimate by looking at ratings/downloads of some of the plugins that already use +python: vimpdb
                Message 7 of 15 , Jun 30, 2010
                  On Jun 30, 3:20 am, Ted <cecinemapasdera...@...> wrote:
                  > 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.

                  Maybe you could make an estimate by looking at ratings/downloads of
                  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

                  --
                  You received this message from the "vim_use" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Marc Weber
                  Hi Ted, 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
                  Message 8 of 15 , Jun 30, 2010
                    Hi Ted,

                    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

                    --
                    You received this message from the "vim_use" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  • Matthew Winn
                    On Wed, 30 Jun 2010 10:34:16 +0200, Marc Weber ... Isn t it rather the opposite? If something requires Python it s at the mercy of the
                    Message 9 of 15 , Jun 30, 2010
                      On Wed, 30 Jun 2010 10:34:16 +0200, Marc Weber <marco-oweber@...>
                      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

                      --
                      You received this message from the "vim_use" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                    • Ted
                      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
                      Message 10 of 15 , Jun 30, 2010
                        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.

                        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...@...> wrote:

                        > Go for Python because VimL can be a lock-in (speed issues if you want to
                        > do a lot).
                        Portability outside of vim is also a consideration in my case, as it
                        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
                        That's interesting. From glancing through the autoload file it
                        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?
                        The URL-parsing code I mentioned earlier is not what I had in mind
                        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.
                        I actually don't know any of those languages either, except for a hint
                        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.

                        --
                        You received this message from the "vim_use" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php
                      • Marc Weber
                        Hi Ted: 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
                        Message 11 of 15 , Jul 1, 2010
                          Hi Ted:

                          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:

                          --
                          You received this message from the "vim_use" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php
                        • AK
                          ... It would be really great if Python became widely included with Vim, there s a very large number of Python developers who use Vim but don t know VimL or
                          Message 12 of 15 , Jul 1, 2010
                            On 06/30/2010 07:01 PM, Ted wrote:
                            > 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.


                            It would be really great if Python became widely included with Vim,
                            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

                            --
                            You received this message from the "vim_use" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php
                          • 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
                            Message 13 of 15 , Jul 7, 2010
                              On 30/06/10 03:20, Ted wrote:
                              > 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. 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
                              >

                              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

                              --
                              You received this message from the "vim_use" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php
                            • Ted
                              Regarding the terminology: My point of confusion with the term a vim script is that, in addition to bearing a similarity to the vimscript or VimL
                              Message 14 of 15 , Jul 7, 2010
                                Regarding the terminology:
                                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...@...>
                                wrote:
                                > On 30/06/10 03:20, Ted wrote:
                                >
                                >
                                >
                                >
                                >
                                > > 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.  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
                                >
                                > 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

                                --
                                You received this message from the "vim_use" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php
                              • Nico
                                ... 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
                                Message 15 of 15 , Jul 13, 2010
                                  On Jun 29, 6:20 pm, Ted <cecinemapasdera...@...> 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. .....

                                  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




                                  --
                                  You received this message from the "vim_use" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php
                                Your message has been successfully submitted and would be delivered to recipients shortly.