[X]Emacs in Java? [was: tlug: Netscape code going public]

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Craig" == Craig Oda <craig@example.com> writes:

sjt> (1) Need a multi-threaded LISP engine to save you from all those damn
sjt>     blocking net-related system calls.  No work is being done now.

    Craig> IMHO, this is a big problem with using Emacs and elisp
    Craig> programs that are designed to get information over the
    Craig> network.  I think that the lack of a multi-threaded LISP

They're out there, just Emacs LISP isn't it.  I think Guile (among
free software) handles threads, and I'm sure there are concurrent
implementations of Scheme.

    Craig> engine will probably move people toward rewriting Emacs or
    Craig> something like it in Java.  It would be great to have

I doubt it.  Lack of pointers will kill you on efficiency.

    Craig> non-blocking calls out to the net in a thread and be doing

"blocking" calls in a separate thread.

    Craig> other work in a different thread then catch the error if
    Craig> the file wasn't accessible from the net.

    Craig> Is there any work to solve this?  Also, JavaMail packages

Netscape does this by creating a server process.  Theoretically Emacs
could too.

    Craig> from Sun now have IMAP support.  So, if Emacs could

IMAP is easy enough to support; I've done a little thinking aobut how
I would interface it with VM using fetchmail.  It's (VM) moderately
complicated uncommented code, so I don't have a prototype yet.   But
the idea is basically simple; you extend the syntax of mailboxes (VM
already supports POP, that's the framework), and use fetchmail to
actually get the mail.

I don't know if fetchmail supports the more advanced IMAP stuff, but
you could add that incrementally once you've got the server talking to
Emacs.

    Craig> interface with Java classes, it would be nice.

I find it hard to imagine either Stallman or the XEmacs crowd using
Java.  Java is a great solution for the "sell the prototype to the
customers" crowd, more efficient than most of the alternatives, and
producing robust, good-looking apps with a minimum of programmer
effort, freeing the programmer to work on the data processing.  But
every implementation (several Macs, Windows, Netscape, jdk) I've seen
is perceptibly slower than equivalent functionality in native code,
and this is for student one-term projects.  Take the performance hit
of XEmacs/Mule 20.3 as compared to Emacs 20.x, and exponentiate it.

Java may be efficient, but it will be in the inner loop---I can't
imagine that [X]Emacs wouldn't take an enormous performance hit,
making it unusable.  Maybe you could do something with native methods; 
then again, maybe that would cost you most of Java's functionality.
---------------------------------------------------------------
Next TLUG Nomikai: 11 March Wed 1998 Tengu TokyoEkiMae 19:30
Chuo-ku, Kyobashi 1-1-6, EchiZenYa Bld. B1/B2 03-3275-3691
Next TLUG Meeting: 11 April 1998 Saturday, Tokyo Station
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096