Re: Perl embedding: trial balloon
John Tobey <jtobey(a)channel1.com> writes:
Woops, I forgot to mention that I'm not currently subscribed, so
please CC: jtobey(a)channel1.com.
Add a "Mail-Copies-To: jtobey(a)channel1.com" header. Almost all of us
are using Gnus and thus you'll get copies automagically.
translations. This probably involves a lot of copying, so it
won't
give optimal performance if implemented naively.
> I presume you already had to introduce perl types for markers and such?
Actually, I haven't got that far. Perlmacs is pre-1.0. But I'm not
sure whether such new types are necessary. Perl can call any Lisp
function and store any Lisp object. It might be nice to encapsulate
these Emacsy types to give them a more Perlish feel someday.
The problem is that if you want a perl binding to be useful beyond
learning how tie language together then you want fast access to the
editor part of XEmacs, i.e. buffers, characters etc. Wouldn't you want
to be able to say.
# Disclaimer
# My Perl is rusty
# count lines in buffer not matching
BUFFER = Emacs::Buffer($name);
while (<BUFFER>)
{
count++ unless /not included/;
}
This gets you immediately into problems because the XEmacs
buffer substring would be in Mule encoding... etc...
Do you have any example of a typical Perlmacs application? Maybe a
Perl port of some standard piece of elisp?
and the finalizer decs it. Since decrementing the refcount can
invoke
user code, this happens after the mark bits have been cleared. I
didn't notice whether XEmacs finalizers have this luxury..
You mean that you want the finalizers to be called after the sweep
fase has been fully completed? This could probably be handled by a
finalizer that puts the object on some "perl ojects to be freed list"
and some general mechanism for functions to be run after the end of
the sweep?
This is my feeling. The Perlmacs patch modifies Emacs very little,
other than to add generic extensibility hooks and a syms_of_perlmacs
call.
Ok fine.
There is one exception, which can be omitted if it is thought
to be troublesome. That is that main() has been overloaded to parse
its command line as perl would if "perl" appears in the invocation
filename. This is especially handy for building and testing
extensions distributed as Perl modules, because it allows one to use
the usual installation mechanisms with PERL=perlmacs. For editing
files, the program is also installed as "pmacs".
That could be handled using some wrapper script at first couldn't it?
It could then be added to the core later if required..
In this case what you really want is XEmacs as a loadable module into
perl!
Jan