🚀 go-pugleaf

  >But Zmacs is so much better than GNU Emacs in so many ways... even down to
  >the datastructures!  GNUmacs is character-oriented rather than line-oriented,
  >which makes a lot of things next to impossible to do.  Lines don't have
  >plists; you can't elide arbitrary sections of text the way VisiDoc does;
  >the first insert after a move in any file larger than ten megs takes up to
  >half a minute (because GNUmacs has to move the one and only one "insertion
  >hole").  Minor modes in GNUmacs are almost impossible to implement correctly.
  >I think TAGS tables suck.  Both conceptually and in the current implementation.
  >I could go on and on...

Yes, I agree on most of this, although I don't quite know what you
mean with minor modes being "almost impossible" to implement
correctly?  The data structures is a big problem, as well as that
C-coded "lisp functions" call other C-coded "lisp functions" directly,
making redefinition in Lisp impossible.  To redefine, rebuild...

On the other hand Emacs is much faster than Zmacs most of the time,
even though it is byte-coded and has a lousy compiler.

Also, I think it's fun to hack in systems that are powerful enough to
be hacker-friendly, but feature-lacking/buggy, like Emacs or Zmacs or
Explorers (or TECO, but that was quite a while ago now).

  >Also all of the GNU Emacs mail readers are substantially more lame.

Yes, but they are much faster (and I guess the machines I run Emacs on
have faster file systems).  I've converted from ZMAIL to RMAIL because
it's faster and the file system is better.  Also, my 1.5MB BABYL file
broke on the Explorer (it was suddenly 5MB, where the extra space was
epsilons, so Zmacs couldn't read it).

  >Hans Chalupsky:
  >>- development environments (such as various fancy lisp-modes for GNU emacs)
  ....
  >
  >Pale imitations at best, and really slow from what I've seen...  The
  >Lispms have the state-of-the-art in development environments, even though
  >they're going the way of the dinosaurs.  But we'll fix that soon :-)

Tell us more, you DO work on a serious Lisp company nowadays...

  >Bjorn:
  >> I think Emacs will eventually have most of Zmacs' "graphic" features (e.g.
  >> multiple fonts), but some of the other bugs are very hard to get out.  And it
  >> will always live with 8-bit characters, which is a loss from the 12-bit LISPM
  >> characters.  You can't both have "clean" ISO 8859-1 and a Meta key, for
  >> instance.
  >
  >I'm not convinced: just because you can't have 12-bit characters in a file 
  >doesn't mean you can't have 12-bit input.  If input was event-based instead of
  >character based, then under X you could easily have seperate keybindings for
  >left-shift-cokebottle and right-shift-cokebottle...

OK, true, but do YOU want to hack Emacs to handle that?  On the other
hand, I think/dream that the world will *eventually* (in 5-10 years or
so) go 16-bit, to cope with larger character sets than ISO 8859-n.
But then all 16 bits will be char-code, and as usual no bits will be
left for Control/Meta/Hyper/Super/Command/Alt/Whatever...  Maybe in 20
years we'll get it again?

  >Do any of you have Explorers at home?  I've often considered buying a used one
  >to play with, but I'm a bit concerned about power/temperature requirements, 
  >and availability of spare parts.  Anyone have any comments?

I've been thinking about it, but I think noise and spare parts are the
preventive issues.

  >		-- Jamie, considering getting CDRNEXT on my license plate.

I like it!  I'll consider CDRNIL (we can only have 6 chars in Sweden,
and my car isn't very fast).

-- Bjorn

Ps.  Hey, I think this list came alive again!?