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

Re: [RFC] Some more python and VimL interfaces

Expand Messages
  • ZyX
    ... Original intend will stop with *.options: in any case nobody can write `vim.options[ lcs ][ eol ]` without first looking at `:h lcs `. This should be a
    Message 1 of 42 , May 12, 2013
    • 0 Attachment
      >> >That is impossible. You may skip some of the list, dict and other Vim
      >> >language features, but when it comes to options, regexp, autocommands
      >> >and many, many other things you need to know how Vim works. Making a
      >> >Python interface for them won't change how Vim works.
      >> >
      >> >For example, you can make some easy way in Python to set the 'tabstop'
      >> >option. To know what the effect is you still need to know about the Vim
      >> >option. Now, since that is a number option it's easy, but when you get
      >> >to the more complicated options you are just doing string manipulation.
      >>
      >> Excluding eval.txt and most common commands is still a big
      >> achievement. Also note that there are no normal VimL interfaces for
      >> what I suggest: I guess after cmdarg() somebody will like to create
      >> cmdadd() and cmddelete(): nobody likes :execute (I am referring to one
      >> of the latest suggested patches).
      >
      >Yes, trying to avoid :execute is good.
      >
      >> >Also keep in mind that the user will still have to type most Vim
      >> >commands. E.g., making a Python way to set an option that is a list of
      >> >names using a Python list might be nice, but the user still sees the
      >> >result as a string and has to type the string when he wants to change it
      >> >manually. Thus you won't be able to just omit this part of Vim
      >> >commands.
      >>
      >> I am completely sure I can hide magic done when using python callables
      >> as mapping rhs or action in a command. Passing sequences and using
      >> sequence-, map- or namedtuple-like objects in options is also a good
      >> idea. Developers are smart enough to guess why after setting &rtp to
      >> ('/usr/share/vim/vim73', '~/.vim') it appears as
      >> '/usr/share/vim/vim73,~/.vim'. And they won’t have to deal with
      >> manual escaping.
      >>
      >> I can’t omit this part of Vim commands. But I can hide it. Also
      >> note that we are not talking about user. There is exactly no
      >> difference for user between modifying option initally set by
      >> import re
      >> import json
      >> lcs = vim.eval('&lcs')
      >> lcs = re.sub(',?eol:.,?', lcs, ',')
      >> lcs += ',eol:$'
      >> lcs = lcs.strip(',').replace(',,', ',')
      >> vim.command("let &lcs="+json.dumps(lcs))
      >> ,
      >> vim.command("set lcs+=eol:$")
      >> ,
      >> # Same as first, but with two modifications:
      >> …
      >> lcs = vim.options['lcs']
      >> …
      >> vim.options['lcs']=lcs
      >> and
      >> vim.options['lcs']['eol']='$'
      >> . Neither there is a difference in the result. But there is difference for
      >> developers as only the last interface is most convenient one.
      >
      >Yes, that looks nicer. At the same time it goes against your original
      >intend: replace Vim stuff with standard Python. The first alternative
      >uses standard Python functions, except for vim.eval() and vim.command().
      >The second one requires the developer to lookup what vim.options
      >actually does and apparently there is some magic that parses an option
      >so that a part of a string can be easiliy replaced. So you added Vim
      >magic inside the Python interface.

      Original intend will stop with *.options: in any case nobody can write
      `vim.options['lcs']['eol']` without first looking at `:h 'lcs'`. This should be
      a wrapper.

      >I rather add some Python functions that handle options. Then
      >vim.options returns the raw number/string, you use the Python functions
      >to manipulate them and then set the option with vim.options again.

      Functions cannot achieve `vim_ext.options['lcs']['eol']='$'`, and I really see
      this more convenient then `vim_ext.set_listchars(eol='$')` or whatever. But
      python classes can.

      >The knowledge that something is a comma separated string then lies with
      >the developer, and he already knows that. He does need to learn the
      >Python function for manipulating option strings, but no Vim stuff.
      >
      >
      >> >We really need to concentrate on the basic, generic mechanisms. Not try
      >> >to make a Python equivalent for every single Vim item. I mean, we don't
      >> >want to replicate every Ex command in Python, right? But we could add a
      >> >Python command that makes it easier to execute Ex commands, e.g. by
      >> >passing the arguments as a list instead of as a string, and indicate
      >> >whether special chars need to be escaped.
      >>
      >> I do not want to replicate every Ex command. I do not want to
      >> replicate Ex commands at all: I am trying to create an interface which
      >> is more convenient then Ex commands. To achieve e.g. suggested
      >> mapadd() you need to write about 15 lines of code. More if you are
      >> writing in python and want to support callables. My suggestion limits
      >> this to only one line by providing similar interface out-of-the-box.
      >>
      >> I am also unsure what are “basic, generic mechanisms”. There are
      >> four things that Vim lacks from my point of view (more significant
      >> first): threading and/or multiprocessing, non-regex syntax, full
      >> support for whatever keys you can find on your keyboard and normal
      >> API. First three are too hard for me currently thus
      >> I am targeting the last one.
      >>
      >> By creating “a Python command that makes it easier to execute Ex
      >> commands” we will just add another source of strange bugs that all
      >> have a fix that looks like “add another `else if strcmp(…)`”:
      >> vim commands are not consistent at all about how should
      >> “argument” look and what, where and how a string should be
      >> escaped. With `vim.command()` we at least can peep at VimL code. With
      >> my interface you will be using C functions directly and thus have no
      >> problems with escaping in addition to having pythonic interface. New
      >> function (python has no commands) will trade benefit for being
      >> error-prone (less benefit over `vim.command` - less bugs, more benefit
      >> - more bugs) and still be non-pythonic and not very useful compared to
      >> `vim.command`.
      >
      >The problem with vim.command is that it's not always easy to escape
      >special characters. At least for commands that take a file name
      >argument this can me made easier. But it can't be done in general,
      >since Ex commands are inherently difficult to parse, and thus difficult
      >to produce.
      >
      >The best way to discover what we need in the Python API is probably to
      >go over existing implementations and find out what functions they define
      >to interact with Vim. Those are pieces of complexity that are repeated
      >often enough that the writer decided to make a function for it. Instead
      >of having every developer write their own functions, those should be
      >provided by the Python API.

      Not really the best. As I said, (almost) nobody is defining mappings, commands,
      functions and autocommands in python code: because now it is easier to write
      *.vim file in addition to a python module. If you try to write such things in
      a python module it will result in having *.vim file embedded as a bunch of
      strings in python.

      I can say that in aurum most used thing is vim_export function that sends data
      to caller VimL function. But it was written two years ago, now I would have
      written a generator function generating pyeval- or fallback :py-based wrappers
      around python callables.

      In powerline *.options would be one of the most useful things (after interfaces
      existed before my patches), getbufvar is used very commonly. Second is bindeval
      again. *.vars will likely be the third. But if there was fast(!) vim.hlgroups it
      would be on the second position: we had to replace checking whether some group
      is a) defined and b) defined with some exact properties with assuming highlight
      is no longer defined after some events because this is too slow even with
      vim.bindeval. This is enough to be done once on each statusline redraw, but even
      in this case using `hlexists()` and a bunch of synIDattr calls is too slow.

      Conque would get some (not much) benefit from bindeval and *.options (if it used
      it) and vim.hlgroups, but much more then that Conque needs non-regex-based :syn
      and more async options.

      I mean, for existing code bindeval, *.options and *.vars (and maybe not written
      vim.current.vars (l: or g:) and vim.current.avars (and for completeness
      vim.current.svars)) is enough. You should look at what was left coded in VimL
      and think why it was coded there. The only plugin intentionally avoiding VimL as
      much as it makes sense is powerline. It has some python initialization (not
      needed if installed with pip), checks what python version should be used (cannot
      obviously be coded in python; but with pip user will already know python
      version), adds workarounds for old Vims without pyeval() and has 44 lines with
      function, option and autocommand definitions. With new interfaces I can replace
      half of them with nicely looking python code leaving only autocommand
      manipulations.

      On ruby side there is Command-T. It has only one *.vim file containing command
      definitions, mapping definitions, a bunch of wrapper functions and ruby
      initialization (this would not be needed if using gem I guess).

      I.e. to get rid of *.vim files it is enough to create convenient interfaces for
      mappings, commands and autocommands; hlgroups is here for convenience and speed
      reasons; others are for convenience: avoiding both :redir and :execute (i.e.
      vim.command). Second problem is non-regex syntax: with conceal feature both
      Conque and Command-T started to use meaningless markers to define syntax
      regions, before Command-T seems to not highlight matches at all (at least now it
      does not without conceal), Conque uses `\%Nl\%>Nc\%<Nc` unless configured to use
      conceal (for two reasons: with concealing it is much faster, but adds garbage
      when trying to copy/paste).

      Pyinteractive has usual commands, autocommands, mappings (and menus which
      I missed), wrapper functions for completion and usual python initialization
      required when using usual way of distributing through vim.org: nothing special.
      But there is one thing I also missed: requirement to use vim.command to get
      colored highlighting. It also calls input() through vim.eval, nothing more
      interesting.

      Python-mode-klen also needs colored highlighting and user interaction (now
      getchar). It defines some interfaces in question (mappings, commands and
      autocommands) using vim.command though. Additionally there are buffer and window
      manipulations. Some things that are easy to write in python were written in
      VimL. It also has hacks for doing something repetiavely.

      Thus fine buffer and window manipulation options would be fine and should be
      added, at first just vim.command+vim.fnameescape. Same for user interaction not
      via callbacks in mappings.

      Colored highlighting should be added; and additionally it would be fine to have
      (both in VimL and in python) thing like :echon that puts the result in
      :messages; I used to miss this when writing colored :! system()-based
      replacement that had to use :echon for this very reason.

      --
      --
      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
      • 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.