Re: lisp interface?
- Gavin Sinclair <gsinclair@...> wrote on 01/11/2002 (11:45) :
> I agree, but do you ever use Vim plugins?Yes, sure. I didn't say I don't want to have plugins.
> If so, do you want to use more or less of them in hte future, and doWhat I don't want is a GNUS in vim if that answer your question. I mean
> you want them to be of greater or lesser quality?
if somebody manage to make something like that it is no problem, but I
don't want that Vim should change just for this sake.
But of course it is not up to me what will happen with vim, just
expressing my view.
I like that vim is faster and uses less memory than emacs. It is just as
usable on an old slow pc as a new.
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
Just vim it.
- "Stahlman Family" <stahlmana@...> writes:
> Sorry. I've looked into the source in if_python.c now, andNo problem - I agree with you entirely over the "not everyone has
> understand a little more about the interface. It looks very
> thorough. It's not that I have anything against the interface or
> Python. It's just that not everyone has python installed, and some
> who do have it installed don't have the python interface enabled;
> hence, plugins or extensions written with the python interface will
> be useful only to a subset of the Vim community.
Python installed" point. It applies to *every* language interface, and
it's what has made all of the existing ones more or less "personal use
[Regarding string/number distinctions]
> I guess you saw Bram's response to this.I did - I had forgotten that fact (unless it was added after I did the
Python interface and I hadn't noticed...) Actually, I really need to
go back to the Python interface and look at it in the light of Vim's
current code - it's not been changed for a *long* time. But part of me
feels that the demand isn't there - "if it ain't broke, don't fix it"
and all that...
> Actually, I don't think it would be all that difficult to addYou may well be right. I think arrays were one of those features that
> support for arrays to the eval implementation in eval.c. Perhaps if
> a growarray * member were added to the union var_val, and the
> growarray array to which it pointed were used to hold struct
> var... Arrays of arrays would be possible. I've implemented
> something along these lines for work. Maybe if I get some time soon,
> I'll play around with it...
a number of prople wanted, but which haven't been implemented for
whatever reason (Bram hasn't needed it, and no-one else came up with a
good patch, possibly).
> Please accept my apologies for having given the impression that I found theNo problem. I didn't take your comments personally, I was just using
> python interface lacking in some way. I do not at all.
the Python interface as the example I knew best - all of the existing
language interfaces have had to address the same issues.
> The problem is, I started looking into Ruby and Python at around theThat's exactly why there are so many language interfaces (and
> same time, and couldn't decide which one to go with. They both seem
> so similar in many ways. Ruby actually seems a little better
> designed to me, but doesn't seem to have caught on here as
> well... Maybe it's because I've done so much procedural programming,
> in so many different languages, that when I discovered Lisp and its
> variants, it was sort of like a breath of fresh air.
conversely, why none of them is a clear "standard"). Language choice
is a highly personal issue, and there's no way of getting agreement on
a standard - Bram would have to make an executive decision. And there
would still be the "not everyone has it installed" issue. [Actually,
if I was feeling like arguing the case, Lua makes a good embedded
language choice. It is tiny, designed to be statically linked into the
application (so no "it's not installed" issues) and highly
flexible. Of course, it's also relatively unknown, so *no-one* would
think it's the right choice - maybe that's an argument in it's favour
Anyway, I hope my point is clear - I personally don't have an issue
with extra language interfaces - the more the merrier - but I don't
think that there's any mileage in trying to get any particular one
"blessed" as somehow more official than the others.
PS One further thought - the language interfaces on Windows
dynamically load the language DLLs. This is incredibly useful, as I
normally build Vim with support for every language I can included,
then the same executable just works using whatever languages are
installed on the client machine. I'd recommend this approach for
any new language interfaces.
This signature intentionally left blank