ZyX wrote:
> > 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:
If most things are already possible, then it should be possible to write
Python functions that work as a nice interface for the functionality.
Thus not change the C implementation of the Python interface.
We also need to keep in mind that all the Vim functionality is nicely
documented and there are examples, while if we add a different way to do
this in Python this requires documenting how that works. Thus a script
writer will have two sets of functionality to learn to use. It will be
good to have "how it's done in Vim" to be very similar to "how it's done
in Python". Otherwise it gets very complicated.
> 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.
This would be a nicer way than using vim.eval(), right?
> 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
For the "expr" options this would currently be done by using pyeval(),
right?
> . 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.
--
GUARD #1: Where'd you get the coconut?
ARTHUR: We found them.
GUARD #1: Found them? In Mercea? The coconut's tropical!
ARTHUR: What do you mean?
GUARD #1: Well, this is a temperate zone.
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.
