>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).
>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.
>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`.
--
--
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.
