>> >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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
