Thanks to all for providing input on my question. I realized that the demographic is a bit more restricted than the general population of vim users; it is that portion thereof who actually install vim modules at all. It's informative to learn that there are some in that group who would not be willing to install python as a module dependency.
At the risk of straying off-topic: is there a consensus on the correct term for a "vim script"? That phrase itself seems too specific, and too easily conflated with one of the files contained in such a package, or any file with the `.vim` extension. I tend to call them "modules", coming from Drupal and Python; Marc here seems to prefer the term "addon"; is there a standard term that should be used to avoid confusion? Marc's response gave me the most food for thought, so I am going to reply to his questions and observations, but much of this applies in a general context (thus the reply to all response). On Jun 30, 5:34 am, Marc Weber <marco-owe...@gmx.de> wrote: > Go for Python because VimL can be a lock-in (speed issues if you want to > do a lot). Portability outside of vim is also a consideration in my case, as it is with any code that's not closely tied to vim's functionality. I guess I'm wondering if it's expected, or at least recommended, that general-purpose routines be re-implemented in VimL rather than being made available through dependencies on other languages. I've written (in addition to the code that prompted my question) some -- decidedly low-rent -- URL parsing code; this is another example of something that is definitely readily available in other languages that vim has bindings for. Without regular additions to the VimL "standard library", ie the set of autoloads and plugins that come installed in $VIMRUNTIME, there ends up being a lot of potential code that is in this ambiguous area. The absence of a widely used system of dependency management [1] means that much of this code may need to be, or has already been, implemented on a module-by-module basis. This is the alternative to having the typical user manually install 6 different modules in order to get something working, or perhaps instead decide that the thing requires far too much effort. Which in turn means that, especially as vim modules become more powerful, there will end up being a lot of redundant code loaded into memory. Or underused scripts. 1: at least to my knowledge; Marc, I am aware of your vim-addon- manager plugin. It sounds pretty useful and is one of those things that I haven't had time to try out and hopefully start using regularly. But it seems like it's not yet widely used, and I would hesitate before taking advantage of its presence by splitting a comprehensive vim module into a set of interdependent components. It's again a question of how open the average user (of addons) is to integrating higher-level tools in order to satisfy their immediate goals. > Maybe you want to get some ideas from my sbt > plugin:www.github.com/MarcWeber/vim-addon-sbt > > It mocks Vim functionality so that you can test it without Vim and use a That's interesting. From glancing through the autoload file it looks like you're just implementing the stuff you need to test that script.. is there a more general purpose vim "test double" Python module somewhere? In addition to various other projects, I've also got a fledgeling drop-in replacement for the `vim` module on the go, after I didn't find anything with some Googles. > Can you tell more about what you're going to implement? The URL-parsing code I mentioned earlier is not what I had in mind when I wrote the original post. The project in question is basically a set of routines for manipulating an outlining/markup file format that I sort of .. accidentally evolved over the past couple of years. The format itself is still fairly nebulous so I don't expect anything to be releasable any time soon. I've not needed anything really high- level so far, but I'm getting to the point where it's going to start saving me time and confusion to have something more complex built. The format is basically syntactic sugar on XML (err, I guess the XML is "on sugar"?), so it could be appealing to eventually be able to use Python's DOM classes to work with it, and in the meantime it would be more convenient to do a lot of the off-the-cuff text processing in Python. For example, I use this format for taking notes, and one of the things that I commonly do is to paste in a quotation from a browser, split it into sentences, and make each of those sentences a "quoted" node, which is just a line which at the right indentation level that contains a double-quote character and a space followed by the sentence. There are a few subroutines inherent to this procedure, and the sentence-splitting in particular is something that could be very context-dependent, with a varying degree of generality: for example, in some cases I want to split out the elements of a list of items, delimited by commas or words like "and" or "or", rather than splitting on sentence boundaries. In other cases I need to specify that the text is already in point form. In Python I would make the basic sentence splitting subroutine the default value of a parameter, and then just override it with a different function, or maybe use a class if it started getting really complex. Although this is doable in VimL, I think it's necessarily a bit ugly, and I would perhaps face censure from would-be contributors if I were to, for example, write a closure by execing a string that contains an anonymous function definition. That being said, VimL is not particularly similar to Python, so perhaps there are better models to be applied than that of Python. If there is a comprehensive coding style guide somewhere, please point me to it; I see a lot of possibilities, especially with respect to copy-prototypal inheritance, but few signs pointing to existing conventions or common techniques. The lack of development in this direction could suggest that people are still tending to do complicated things in bound languages (Python, perl, etc.), or perhaps external tools (though this would seem to be more of a portability issue than most languages). Or it may perhaps just indicate a desire to prevent vim from expanding into an operating system lacking a decent editor. I'm currently experimenting with making the top-level function a dictionary function, and using the dictionary as I would, in Python, use keyword arguments. To this end I wrote some code to make it convenient to copy the prototype dictionary that contains the function and its defaults, while applying options, and then call the function. It ends up using method chaining and being somewhat Javascript-ey. I called it "Merger": it has Ours (keeps defaults), Theirs (overrides defaults), and Safe (throws exceptions on conflict) methods, as well as recursive versions of said methods, which deepcopy the original and merge in their dictionary parameter, then return the result. There are also some methods like Apply and Call that make it easier to call dictionary or non-dictionary functions on the object. It appeared to me that, although not particularly complex (I think the whole thing is about 40 lines), it should really go into some kind of general-purpose library or into a separate module. I remembered that I had a few of those in my list of things that might be useful later on, and I should probably scan through them to see if this sort of thing is implemented in any of them. But they seem pretty time-consuming to go through, and I was a bit worried that the procedure might, at this point, cause my brain to have some sort of stack overflow error from yet another level of sub-task. I also thought that if this module that I'm building is going to depend on a separate utility module, and at this rate likely 6 or 10 others, how much more of a portability issue is it going to be to just write the whole thing in Python in the first place? And thus my question. > :-). Vim does neither support Scala, F# nor Haskell. Maybe you should be > using lisp or scheme then. I actually don't know any of those languages either, except for a hint of lisp. Actually my use of the term "functional programming" should probably be taken with a grain of salt; my experience in this respect is mostly limited to what's possible in Python through the `itertools`, `functools`, and `functional` modules, and through the use of closures. But I like what I've learned of it so far. -- You received this message from the "vim_use" 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