On 09-May-2013 00:54 +0200, ZyX wrote: > > > [10 sentences deleted] > >> 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.
Good explanation of the pain points. My take on this is: Vimscript is made primarily for interactive use, and therefore it is difficult to write watertight plugin code that works under all circumstances. It's great to be able to write :! python % when you know the Python in your PATH is the right one, and your file doesn't contain spaces, but in a plugin, you have to pull together configuration variables, executable(), fnamescape(), etc., and it gets messy quickly. Likewise, :map is often right for ad-hoc mappings, but all plugins should use :noremap. Same for 'ignorecase'. > [2 sentences deleted] > > 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. For me, it's again the trade off (or historical accident) that was made in favor of easy migration from ad-hoc macros to mappings to full-fledged personal plugins to published plugins. The great thing is that it's Vimscript all down that path, the downside is that what was a simple one-liner has to be rewritten to a complex dozen-line function (with stuff that has to be tediously learned) in order to be fully robust under most users' customizations. On the other hand, maybe we're holding ourselves to too high ideals. Most plugins I've tried and reviewed (even from venerable long-time contributors like Tim Pope or Dr. Chip, though admittedly much less so) have certain deficiencies or break when used with obscure settings or environments, but most people are happy to use them, anyway. So I tend to defend Vimscript on its "worse is better" philosophy when language purists try to bash it too much. But I would be happy if a different approach (like your planned much-extended Python interface) turns out to be as productive without so many pitfalls. > [11 sentences deleted] -- regards, ingo -- -- 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.
