> 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.
Nope. It is now when script writer has to know “how it is done in Vim” in addition to knowing vim<-->python interface. Target of the new interfaces is that plugin writer has to know only if_pyth.txt for all things he may need to do. RFC is here to discuss how implementing my proposal completes this target and what other things need to be included. And adding python interface that is the same as VimL is 1. throwing away some of the benefits python provides 2. intentionally creating interfaces with design flaws 3. intentionally ignoring python principles like “explicit is better then implicit” (for 2. and 3. refer to my explanation of why *.options are written the way they are written). Not saying that I can’t imagine how to write VimL in python. > For the "expr" options this would currently be done by using pyeval(), > right? For *expr options, and map-<expr> this will be done using pyeval() even after the patch; for :command it is now and will after be done using :python. What the patch will add is a) Standard interface. b) No need in knowing and using VimL. Exact implementation will be hidden. c) When core vim features will allow this, implementation will change. 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). -- -- 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.
