> I've seen your many recent Python patches, and it's certainly good to > have more things exposed in a native language way. However, I'm a bit > concerned if (but I know too little about your patches to be sure) you > have to write all the plumbing from Vim's internal structures to the > Python interface in a Python-specific way. I would prefer if most of the > plumbing were done in Vim core, so that Vimscript as well as other > language integrations could easily benefit. I imagine that the object > model of Vimscript, Python, Perl, Ruby, Lua, etc. are similar enough > that if all that access functionality existed in Vim core, each > integration could get at that with a very thin language-dependent bridge.
You can review the patches. Most code is converting arguments and result to/from PyObject* and error-checking, there is not much that can be moved to core. I can’t generalize things like WindowAttr for e.g. lua: it cannot be used because WindowAttr returns PyObject* and in lua it would “return” void and push to the stack. Not saying I do not know other APIs. Things that make sense to put in core I put in core, but there are not much: in that sequence I only added functions for finding windows, temporary switching to specific window+tabpage and stricter get_option_value. > To put it in another way: Christian Brabandt recently implemented a > Vimscript getsign() function and extended exists() to be able to access > the sign information. I would hope that your vim.signs implementation > could leverage most of that from Vim core. It would be bad if your > implementation is a completely separate access of the core Vim > structures, because of: > - duplication = code bloat As I said I add to core what makes sense to be added there. Most of code in if_py_both is data conversions from C types to PyObject* and back, error handling or other python-specific stuff; I see no candidates for moving to core (obviously does not mean there are no). Code is mostly trivial, but hard to write (for a high-level language user) due to its amount and amount of things that need to be cared about (exceptions, failed memory allocation, decref/incref, rarely alloc/free, etc). > - other language integrations will eventually want to have the same > access; each has to tediously reinvent the wheel, and will probably do > so inconsistently Other languages’ integrations should be consistent with other languages’ best practices, not with python or VimL. Python users would not be happy with vim.lock(dict) in place of setattr(dict, 'locked', True) (dict.locked = True), but VimL uses first variant (with a command though). dict['abc']['def'] may be expected to throw an exception for absent 'abc' or 'def', or return undef and create a dictionary for key 'abc' (and even do this depending on options; I am talking about perl here, though dunno whether you can create a vim.dictionary there). > - since maintenance is separate for each language, we end up with Python > abilities for A, B, and C, Vimscript access for A & B (and use of :redir > for C), and e.g. Ruby access only for C. Yup. It would be good if there was a ruby user+developer to port my changes to ruby though. As I said most code is service one, lua won’t benefit from code that transforms to PyObject* handling errors in the middle, so you can expect extending lua being just as hard (or harder/easier depending on its C API) as extending python, with a small help from a small amount of functions that are general enough to have them in core. > > Maybe I even won�t forget about the discussion after both API and > > implementation are finished. The thing I won�t add to python though is > > vim.capture: usage of :redir only means some API is missing and that is the > > problem that should be fixed. > > Don't get me wrong; I appreciate your efforts to improve the Python > interface. I'm just a bit afraid that in the future, people will use > Python just because there's no equally convenient way to access the > information from Vimscript. To me, that would be bad. The Vimscript API > should remain the first-class, full interface (that doesn't preclude > other languages from having an equally rich interface), so that other > languages are chosen based on their merits (mostly familiarity and > external APIs that not available inside Vim), not based on need. To choose other languages for their familiarity/*external* APIs somebody needs to find another person to write all the things I am implementing for Python and this would be good. I don’t think I will live long enough to see when you could choose language for vim plugin without taking vim<->language API into account. Also don’t forget that A and B that are not in ruby can be accessed through VimL layer. VimL being a first-class is not a good thing because of a big number of issues not fixable due to either backwards compatibility or too big codebase changes that require to fix them; if I was sure vim users are required to have some language but VimL I would immediately switch to it. Though you have a point about another languages: things have to be added to VimL because this way they automatically “appear” in other supported languages. Note though that VimL additions I can design will much likely smell python, but python has iterators to walk through vim.mappings without allocating a big list by a small chunks (you can’t do one alloc for all list items in C code and expect it not to crash as a consequence) and tp_as_mapping->mp_subscript to not allocate a big nested dictionary just for querying for autocommands['Powerline']['VimEnter']['*']. When you will see my VimL APIs in RFC please be captious. -- -- 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.
