>Would it be possible to have most Vim functions made callable from
>Python this way? Obviously it's much better than using vim.eval().
I assumed it be a convenience wrapper replacing
vim.bindeval('function("bufnr")')('%')
(obviously, you can save `vim.bindeval('function("bufnr")')` result in
a variable) with a nicer syntax. I believe author of proposal assumed the same.
>An example from the help:
>
> :py tagList = vim.eval('taglist("eval_expr")')
>
>Would then be something like:
>
> :py tagList = vim.functions.taglist(eval_expr)
>
>With the difference that eval_expr would be a Python expression.
You mean, python regex? I already thought about it (but not applied to
`vim.functions.*`). It is not too hard (if written in python), but I never
heard
about functions working this way (i.e. when you need regexes you take `re`
module, take generator/list expression, for cycle or whatever and do what you
want). Unlike Perl here regexes are not the part of the syntax and even not
very
significant part of the language thus I assumed this behavior will not be
expected if expr is string and not necessary if you have iterators.
>For the internals we would need to have a list of all funtions with
>their argument types, so that the arguments can be converted from Python
>to the Vim type. Could be added to the functions array in eval.c
>
>A big advantage is that it's going to be much easier to add
>functionality both to Vim and the Python interface.
For types that are already in VimL you need nothing: they are converted
automatically. To use regexes, expressions and such things that are “types”
only
for humans, but not for VimL function, from python much more job needs to be
done. From my point of view the best you can do is provide good API for such
things. E.g. for tags this would be sequence-like `{buffer}.tags` (or
`vim.current.tags` depending on what is there on the C level) with
namedtuple-like objects so you can filter tags using
def get_taglist(regex):
for tag in vim.current.tags:
if regex.match(tag.name):
yield tag
taglist = list(get_taglist(regex))
that usually narrows down to just
taglist = [tag for tag in vim.current.tags if regex.match(tag.name)]
. Note though that the following is completely possible with my first (one that
introduced `pyeval`) python patch:
vim_taglist = vim.bindeval('function("taglist")')
alltags = vim_taglist('.*')
. But for e.g. help buffers with `len(taglist('.*')) == 15550` this takes
9 seconds to complete in VimL and same in python (even if I forcefully convert
the result to a python list of python dicts: likely problem is in requirement
to
allocate a very big bunch of small memory pieces using libc malloc: without
profiling I can’t imagine other explanation of why creating just the same
number
of python objects adds insignificant amount of time). Thus you don’t want
vim.functions.taglist using taglist implementation from eval.c at all, you need
direct python → C interface to work with such amount of tags flawlessly.
Note that I know at least one case when I need *all* tags: to know what to look
at when converting help files to HTML using format.vim. taglist() function
listing only tags present in the file would do the job, but it is not there and
I do not expect existing one to work fine (i.e. with fine performance) if
I would e.g. continiously feed continiously truncated tail of the line into
`taglist()` to determine whether there is a tag.
This is another reason why it is better to have native python interfaces
written
in C: while after adding bindeval I have reduced performance issues to the
lowest value possible without changing architecture of aurum for aurum, but
other plugins needing other parts of Vim will still suffer from them every time
they will use `vim.*eval` or `vim.command`.
By the way, thanks for pointing to another thing that need nice python
interface.
--
--
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.
