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

Re: [RFC] Some more python and VimL interfaces

Expand Messages
  • Andy Kittner
    ... I took some time today to look more closely at the RFC and the other resonses in this thread. I also played around a bit with creating a meta-plugin that
    Message 1 of 42 , May 12, 2013
    • 0 Attachment
      On Fri, May 10, 2013 at 03:49:45AM +0200, Bram Moolenaar wrote:
      >
      >ZyX wrote:
      >
      >> This is a description of proposed new python interfaces.
      >
      >Well, that's a very long list. Do we really need all of this?
      >Let's at least order by usefulness.

      I took some time today to look more closely at the RFC and the other
      resonses in this thread. I also played around a bit with creating a
      "meta-plugin" that would allow writing python-only plugins, just to
      get a feel of things. So, with all that in mind here is my priorized
      wish-list:

      0. We all seem to agree that a complementary pure python module is a
      good idea. Where it make sense to do so parts of the proposed
      improvements cab be added there, and it will also give us a nice home
      to add more convenience functions (e.g. for dealing with some ex.
      commands) later.

      1. Add the ability to create a FuncRef for arbitrary python callables:
      The extra book keeping required to do this now feels unnecessarily
      complicated and I think performance-wise the indirection
      (vim_function -> id2callable registry -> python function) will
      probably be noticeable for many repeated calls (e.g. when used in
      a sub-replace-expression in a big file)

      2. Ability to create / remove autocommands, maps and user commands:
      The fully introspectable mappings mappings as proposed by ZyX would
      be awesome, but at a bare minimum a convenient API for creation and
      removal should be available

      3. vim.functions:
      Again, the introspection is not strictly necessary, but a convenience
      wrapper that pulls the FuncRefs will make code look much nicer.
      In that regard I'd also offer attribute access for builtin/ global
      functions in addition to the getitem syntax. That way you can do
      things like:
      curbuf = vim.functions.bufnr("%")

      4. $thing.valid for buffer, window, etc. objects
      Being able to tell whether a reference to one of those is still
      usable seems quite useful to me

      The above are the most useful I think,


      5. vim.signs & related

      6. vim.jumps & related

      7. vim.hlgroups % related

      8. vim.find_buffer
      This one would make more sense as a method on vim.buffers for me

      9. anything else ;) it is an extensive RFC after all (Thanks very much
      for writing it up and for working on improving the Python bindings in
      general btw.)

      Regards,
      Andy
      --
      Happiness is just an illusion, filled with sadness and confusion.
    • 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
      • 0 Attachment
        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.