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
No comments:
Post a Comment