Re: Perl embedding: trial balloon
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "John" == John Tobey
<jtobey(a)channel1.com> writes:
John> I personally will be happy if all Perl support goes through
John> funcall.
This would be rather slow for typical Perl-ish direct buffer
manipulations, I should think.
Why? funcall may be considered "slow" in comparison to C and other
lisp implementations, but it's certainly not *that* slow.
John> Maybe things like car and cdr can avoid it for
John> speed, but that will happen in a Perl module (Emacs::Lisp)
John> and will not touch the xemacs binary.
??? Why would Perl code go ripping into list structure? It was in a
different context, but you did write "I want Perl to chew on the text
in my buffer".
I believe he wants Perl to be able to access anything Emacs Lisp is
normally able to access. Buffer text is only one obvious example.
"This XEmacs is Perlmacs-enabled. That means that nothing can
be
relied upon to behave like it used to (although as far as we know it
does, we cannot _prove_ that it will continue to do so), and you could
experience severe data loss unless you carefully check all possible
Lisp/Perl interactions in all packages that you may explicitly or
implicitly load."
I dislike the possibility of Perl support for other reasons, but I
must say that it wouldn't make things that bad. What you quoted might
as well run like this:
"This XEmacs is Windows-enabled. That means that nothing can be
relied upon to behave like it used to (although as far as we know
it does, we cannot _prove_ that it will continue to do so), and
you could experience severe data loss unless you carefully check
all possible Windows interactions in all packages that you may
explicitly or implicitly load."
Such a saying cannot be proven nor disproven, and can apply to just
about anything.
to the splash screen. That's what Kyle was saying, although much
more
politely.
John> So, if I understand you, XEmacs can be linked as a library
John> and dynamically loaded? What about unexec?
Yes to the first.
Huh? Are you sure of this? Because I'm sure as hell not. I believe
the "external widget" code actually fires up a copy of XEmacs and
talks to it through X. Talking to John about external widget is
side-tracking, because that's not what he's interested in.