ZyX wrote:
> >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.
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.
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.
--
CUSTOMER: Well, can you hang around a couple of minutes? He won't be
long.
MORTICIAN: Naaah, I got to go on to Robinson's -- they've lost nine today.
CUSTOMER: Well, when is your next round?
MORTICIAN: Thursday.
DEAD PERSON: I think I'll go for a walk.
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
