> Well, that's a very long list. Do we really need all of this?
> Let's at least order by usefulness. First add things that help
> plugin writers most. I'm assuming that very few users will type
> Python commands, I expect them to be used in scripts.
> We could lower priority for things that are already possible but
> perhaps not in a very nice way.
They are all possible (except for some edge cases like `<script>` mappings
(maparg(dict=1) does not distinguish between `nore` and `<script>` mappings),
`<LT>F1>` vs `<F1>` in lhs when using `:redir` to get list of mappings,
determining whether some column in :jumps output is file name or line in the
buffer, determining function name used for custom/customlist completion and so
on). And all help plugin writers. The least useful for me would be jumps thing,
but other plugin writers would not tell the same. Like all python interface
improvements this reduces the need for `vim.command` and `vim.[bind]eval`. Main
target is to reduce VimL in scripts that require python support to just one
line `:python import foo; foo.setup()` call and have nice python code. Then
python-enabled plugins are easily installable by pip with the single addition
of that line to vimrc. Additionally python-only plugins will be able to be
written in python and not in python+VimL. Currently people are not doing the
former because this still requires a bunch of things written in VimL and
wrapping this into `vim.command('''{multi-line}''')` does not look good and the
latter is just not possible. There are a few more things to be added for this
to work:
vim.functions:
Mapping-like object mapping user function names to vim.Function objects.
Accepts s: and <SID> in keys, but always expands it when creating objects.
function:
Callable object with the following attributes:
name Function name
code Function code
sid Script ID
is_dictionary True or False.
dict For convenience vim.Dictionary can be assigned to this
attribute in order to forget about specifying self= arg.
Supports assigning any mapping-like object that can be
converted.
vim.Function(args, code, name=None, is_dictionary=False, dict=None)
Creates function object like above (name=None means anonymous function, name
is automatically generated). Code is a iterable of strings.
vim._gen_function(callable, args=())
Generates vim.Function object from python callable object. At this point
can only do something like the following (but not exactly this; and also
written in C):
id = vim._callables.save(callable)
return vim.Function(args, ('python import vim', 'return
pyeval("vim._callables[{0}]({1})")'.format(id,
','.join((arg+'=vim.bindeval("a:'+arg+'")' for arg in args)))), dict={})
# Rather hacky, but standard solution is preferred over 100500 ways
# plugin writers can reimplement it just to call python function
# from various places where it is needed.
. Is not supposed to be used directly: it is for
vim.Command(command=callable), vim.Autocommand(command=callable) and
vim.Mapping(rhs=callable, expr=True).
In vim.Autocommand(command=callable) callable receives buf=N (for <abuf>) and
match=string (for <amatch>) keyword arguments.
In vim.Command(command=callable) callable automatically receives a list of
arguments in args keyword argument and additionally count=N or range=(N, M),
bang=True/False and reg=char keyword arguments if appropriate.
In vim.Command(complete=callable) callable receives three arguments as usual
completion function. It is the only callable that receives non-keyword
arguments.
In vim.Mapping(rhs=callable, expr=True) callable is called without arguments.
vim.options, {buffer}.options and {window}.options should also support
assigning python functions when it makes sense:
&statusline: will use something like %! and receive vim.window argument.
&indentexpr, &formatexpr, &balloonexpr, &foldexpr, &diffexpr, &includeexpr,
&patchexpr, &printexpr
&omnifunc, &completefunc, &operatorfunc
. As when deleting commands, mappings, autocommands and resetting options no
GC is triggered this will use pyeval() directly as long as possible (i.e. no
need to make GC’ing functions also GC objects from vim._callables as functions
will not be garbage-collected). vim._callables will have .remove() method in
case somebody will need to GC things manually. vim._callables won’t contain two
references to same object.
--
--
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.
