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

Re: [RFC] Some more python and VimL interfaces

Expand Messages
  • ZyX
    ... I assumed it be a convenience wrapper replacing vim.bindeval( function( bufnr ) )( % ) (obviously, you can save `vim.bindeval( function( bufnr ) )` result
    Message 1 of 42 , May 15, 2013
      >Would it be possible to have most Vim functions made callable from
      >Python this way? Obviously it's much better than using vim.eval().

      I assumed it be a convenience wrapper replacing

      vim.bindeval('function("bufnr")')('%')

      (obviously, you can save `vim.bindeval('function("bufnr")')` result in
      a variable) with a nicer syntax. I believe author of proposal assumed the same.

      >An example from the help:
      >
      > :py tagList = vim.eval('taglist("eval_expr")')
      >
      >Would then be something like:
      >
      > :py tagList = vim.functions.taglist(eval_expr)
      >
      >With the difference that eval_expr would be a Python expression.

      You mean, python regex? I already thought about it (but not applied to
      `vim.functions.*`). It is not too hard (if written in python), but I never heard
      about functions working this way (i.e. when you need regexes you take `re`
      module, take generator/list expression, for cycle or whatever and do what you
      want). Unlike Perl here regexes are not the part of the syntax and even not very
      significant part of the language thus I assumed this behavior will not be
      expected if expr is string and not necessary if you have iterators.

      >For the internals we would need to have a list of all funtions with
      >their argument types, so that the arguments can be converted from Python
      >to the Vim type. Could be added to the functions array in eval.c
      >
      >A big advantage is that it's going to be much easier to add
      >functionality both to Vim and the Python interface.

      For types that are already in VimL you need nothing: they are converted
      automatically. To use regexes, expressions and such things that are “types” only
      for humans, but not for VimL function, from python much more job needs to be
      done. From my point of view the best you can do is provide good API for such
      things. E.g. for tags this would be sequence-like `{buffer}.tags` (or
      `vim.current.tags` depending on what is there on the C level) with
      namedtuple-like objects so you can filter tags using

      def get_taglist(regex):
      for tag in vim.current.tags:
      if regex.match(tag.name):
      yield tag

      taglist = list(get_taglist(regex))

      that usually narrows down to just

      taglist = [tag for tag in vim.current.tags if regex.match(tag.name)]

      . Note though that the following is completely possible with my first (one that
      introduced `pyeval`) python patch:

      vim_taglist = vim.bindeval('function("taglist")')

      alltags = vim_taglist('.*')

      . But for e.g. help buffers with `len(taglist('.*')) == 15550` this takes
      9 seconds to complete in VimL and same in python (even if I forcefully convert
      the result to a python list of python dicts: likely problem is in requirement to
      allocate a very big bunch of small memory pieces using libc malloc: without
      profiling I can’t imagine other explanation of why creating just the same number
      of python objects adds insignificant amount of time). Thus you don’t want
      vim.functions.taglist using taglist implementation from eval.c at all, you need
      direct python → C interface to work with such amount of tags flawlessly.

      Note that I know at least one case when I need *all* tags: to know what to look
      at when converting help files to HTML using format.vim. taglist() function
      listing only tags present in the file would do the job, but it is not there and
      I do not expect existing one to work fine (i.e. with fine performance) if
      I would e.g. continiously feed continiously truncated tail of the line into
      `taglist()` to determine whether there is a tag.

      This is another reason why it is better to have native python interfaces written
      in C: while after adding bindeval I have reduced performance issues to the
      lowest value possible without changing architecture of aurum for aurum, but
      other plugins needing other parts of Vim will still suffer from them every time
      they will use `vim.*eval` or `vim.command`.


      By the way, thanks for pointing to another thing that need nice python
      interface.

      --
      --
      You received this message from the "vim_dev" 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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Bram Moolenaar
      ... Yes, this also came up as a side effect of the os.chdir() solution. It s especially useful if a plugin can be distributed as a Python module plus some
      Message 42 of 42 , May 21, 2013
        Marc Weber wrote:

        > Yet another suggestion - what about adding &rtp to sys.path somehow ?
        > (with or without python version site-packages or the like)
        >
        > Then you could
        > - write .py files
        > - use them from python by
        >
        > import module
        > do_stuff()
        >
        > Yes - it can be trivially implemented in tools like vim-addon-manager,
        > but I'd prefer a global solution usable by everyone.

        Yes, this also came up as a side effect of the os.chdir() solution.

        It's especially useful if a plugin can be distributed as a Python module
        plus some lines in the Vim plugin. It would have a similar effect as
        using a Vim script under autoload.

        --
        A M00se once bit my sister ...
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        You received this message from the "vim_dev" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      Your message has been successfully submitted and would be delivered to recipients shortly.