Thanks for the reply.
>I took some time today to look more closely at the RFC and the other resonses
>in this thread. I also played around a bit with creating a "meta-plugin" that
>would allow writing python-only plugins, just to get a feel of things. So,
>with
>all that in mind here is my priorized wish-list:
>
>0. We all seem to agree that a complementary pure python module is a
> good idea. Where it make sense to do so parts of the proposed
> improvements cab be added there, and it will also give us a nice home
> to add more convenience functions (e.g. for dealing with some ex.
> commands) later.
>
>1. Add the ability to create a FuncRef for arbitrary python callables:
> The extra book keeping required to do this now feels unnecessarily
> complicated and I think performance-wise the indirection
> (vim_function -> id2callable registry -> python function) will
> probably be noticeable for many repeated calls (e.g. when used in
> a sub-replace-expression in a big file)
This is one of the ideas behind
>About c): I still have not forgot about suggestion I have written earlier
>about
>function references: making them more generic by embedding struct func_S
>pointer in place of char* with function name. There are two additions since
>then: no s: in function references, reference counting for all (not only
>anonymous) functions (implies holding normal user functions in a regular
>dict_T
>like g: one, but hidden(?)), reference counting in struct func_S and normal
>names for anonymous functions (they will not be added to dict_T as with
>reference count and all other data in a structure attached to typval_T* unique
>names and holding anonymous functions with other user functions are no longer
>needed).
>2. Ability to create / remove autocommands, maps and user commands:
> The fully introspectable mappings mappings as proposed by ZyX would
> be awesome, but at a bare minimum a convenient API for creation and
> removal should be available
>
>3. vim.functions:
> Again, the introspection is not strictly necessary, but a convenience
> wrapper that pulls the FuncRefs will make code look much nicer.
> In that regard I'd also offer attribute access for builtin/ global
> functions in addition to the getitem syntax. That way you can do
> things like:
> curbuf = vim.functions.bufnr("%")
Good idea.
>4. $thing.valid for buffer, window, etc. objects
> Being able to tell whether a reference to one of those is still
> usable seems quite useful to me
>
>The above are the most useful I think,
>
>
>5. vim.signs & related
>
>6. vim.jumps & related
>
>7. vim.hlgroups % related
>
>8. vim.find_buffer
> This one would make more sense as a method on vim.buffers for me
And this as well. Will update the RFC at
https://gist.github.com/ZyX-I/5561409#file-rfc-rst.
>9. anything else ;) it is an extensive RFC after all (Thanks very much for
> writing it up and for working on improving the Python bindings in general
> btw.)
--
--
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.
