> > 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). > > Yes, due to the mismatch between the C code in core and the mostly > object-oriented APIs of other languages, I had assumed that there is > quite some boilerplate code. If any of that could be wrapped for reuse > [by other language integrations], either through macros or helper > functions, that would be desirable.
To do this I need to know other languages APIs. And have to create a “header” file if_interp.h really containing C code like if_py_both.h (never added any files to vim except for tests and runtime ones). And have to write something that uses such functions in e.g. if_ruby.c: there is no other way I can prove this generalization necessary. Thus if some ruby developer will want to extend ruby in a similar way it would be he who should write generalization: I just do not have enough knowledge and time to do this. > I've heard the dislike of Vimscript, but much of that is probably due to > the developers' relative unfamiliarity with it. For extensions that are > closely related to text-editing, I found it quite nice and powerful, and > there is no mismatch between the Vim API and another language to bridge. > But I agree that other stuff (e.g. any interfacing with external systems > or networking stuff) is extremely hard (though people have written > hashing functions or JSON parsers in Vimscript). This is not a problem with other stuff. I have to care about a big bunch of options like &ignorecase. I have to always remember about strange defaults (:map without nore while best practices tell nore should be default, :command without -bar while most commands will be more convenient to use with it and so on). I have to remember about escaping, and correct escaping (three common escaping variants for different cases). I have to forget about writing some neat code because it does not work reliably (e.g. :!python %). I have to generate a big number of lines just to take care of NUL case when in python it is just a regular symbol. Even in zsh it looks like a regular symbol though zsh uses just the same NUL-terminated strings. I have to know about some inconsistencies which will never be fixed due to backwards compatibility. Do you know that there is no option for filename completion in user-defined commands except for `custom…`? I have to hope user have sane configuration. Did you ever hear python `subprocess` module refusing to work because user has wrong configuration options? Also try to write down rules for dividing a string into a list of statements for python and for VimL and compare it. There is no such thing like a bunch of variants of handling newline depending on the bunch of variants of non-immediately-surrounding context† in python. By the way, I have written both (adler32 hash (math was easier then base64 encoder/decoder which I used to write too) and both YAML (superset of JSON) and JSON parsers). And even a DSL for describing (and validating and completing) function and command arguments. Developers do not like VimL not because they do not know it. They dislike it because they do. I cannot say there are no things that bug me in python, zsh or perl (high-level languages I know good enough to judge, best known first), but VimL is the only one that bugs me that much. I have to say though that when I was writing some simple things it seemed good, but “the farther into the forest, the thicker the trees”. I just did not know all the cases where my simple things can break and did not care about them. † (NL in file, NL in file followed by spaces and backslash, NL in execute after commands not taking | as an argument, NL in execute after other commands, NL in execute after (built-in!) command taking expression (:echo) and unclosed quote, NL in execute after :function): main questions to answer are whether we are in a file, in a Ex prompt (BTW, have not explored this), in an :execute or in a function inside :execute. And what is the command we are computing arguments for. > > 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. > > Certainly, Vimscript won't win any performance contest; other language > interpreters are probably way more optimized. They are. Problem is not with optimizations, problem is some set of features like concurrent processing and a number of places where globals are used. > Thanks for all your explanations; you indeed have very deep knowledge in > this area. I'm looking forward to your patches and improved Python > integration! Good luck! -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
