> From: "Tolkin, Steve" <[EMAIL PROTECTED]>
> Cc: Boston Perl Mongers <[EMAIL PROTECTED]>
> Date: Fri, 26 Jan 2001 16:38:05 -0500
>
> Dear John,
> I saw in the new modules listing that you recently posted
Ever the watchful one, Steve. :)
> http://search.cpan.org/search?dist=Emacs-EPL-0.1
Dang! I put an empty README file in that tarball. Well, the
executive summary is: This new thing is the very first unstable
release of EPL (Emacs Perl). Both EPL and Perlmacs allow you to
script Emacs using Perl in addition to its native language Lisp. The
difference is Perlmacs is an embedding, while EPL uses pipes and
subprocesses. This makes EPL much more portable and easier to
install.
> (a way to customize Emacs using perl rather than elisp.)
> So I downloaded it from your home page.
>
> But you say it requires Emacs 21 (not yet generally available).
> Do you know when Emacs 21 will be released?
No, but it's been through five betas since November.
> Is it stable enough for me to use on Windows NT in its current state?
> What new features does it bring?
Emacs 21's Windows port is pretty solid as far as I can tell, not
having used it. It has a lot of features borrowed from XEmacs,
including inline images, a toolbar, and on the Lisp side, native hash
tables, including weak ones.
The weak hashtable feature is what EPL 0.1 needs that isn't in earlier
Emacses. To get by without it, we'll have to require Lisp code to
explicitly free referenced Perlstuff or leak memory.
> One possible reason I might want perlmacs would be to have minimal
> munch semantics on certain searches, e.g. m/x*?/
> but I hear this is planned to be built into Emacs 21,
> and its about time.
Yes, Emacs 21 has this, as does XEmacs.
> I might want to be a guinea pig (beta tester) for perlmacs someday if there
> are enough advantages.
I don't know what advantages it has, if any. ;) You are welcome to
try it out, but be wary of 0.1 alpha releases. A bug in this one can
put the perl subprocess in a very fast stack-eating loop, so sync
early and often.
> Besides preferring Perl over Lisp, and the existence of
> many perl modules, which are good reasons,
> is there any major functionality that can be achieved
> using perlmacs rather than emacs?
Dynamic loading, e.g. of database drivers. Not saying whether that's
a good idea.
> I recall RMS once stating that emacs was always going
> to assume 32 bits for an int and a pointer. Now that
> 64 bit chips are here (sort of) and machines have
> big physical memory I am wondering if this is still true.
I don't know. I hope it lets you open >256MB files someday. Then
again, why would anyone ever need more than 640K?
> One possible reason for perlmacs might be to let
> me use Perl to have emacs run code that takes advantage
> of 64 bit very large address.
Yes, I suppose so.
> If perlmacs is reasonably solid I'd love to hear abvout it at some future
> Bostom PM meeting.
I'll yammer on about it until somebody gently nudges the bottom of my
chin upwards.
-John
