Re: redisplay system of emacs

["Stephen J. Turnbull" <stephen@xemacs.org>]

grischka writes:

 > But as is, emacs comes with an implicit structural clause to its
 > license, as in "[You may convey a work based on the Program, ...]
 > BUT WE DO OUR BEST TO PREVENT THAT."

That's simply not true.  There have historically been a large number
of editors based on Emacs code, some of which are in active
development (of course XEmacs is an example, and many wilder
alternatives have existed: pymacs, perlmacs).  And every long time
user has more or less substantial app-specific code in their init
file, while many have private branches, sometimes shared with friends.
Corporate IT departments often have quite substantial applications
built on Emacs (a friend of mine feeds his family by maintaining a bug
database query frontend in Emacs Lisp for a leading technology company
-- that's his fulltime job).

I can say to those who say "we can rebuild Emacs using third-party
libraries and it would be more maintainable and flexible" that XEmacs
has tried that several times for different areas of functionality, and
for one reason or another the code has always come back out again.  In
fact, those third party libraries have always either turned out to
lack the flexibility demanded by an editor application, or to be less
stable than XEmacs itself, and since they didn't offer any high-level
capabilities that couldn't be coded in three lines of Lisp, they went
back on the shelf.

Of course low-level facilities like displaying glyphs from fonts are
best done with specialized libraries.  Guess what?  Emacs uses native
X for legacy fonts, but it doesn't go to Xrender for scalable fonts,
it uses freetype and/or Xft.  But even at the level of displaying
images which you would think would be eminently suitable for a third-
party library like libmagick or maybe netpbm, XEmacs was forced to
abandon its attemtp to use libmagick as a common interface to all
image formats, and go back to direct support of the various underlying
libraries such as libjpeg and libungif -- which itself turned out to
be too unstable, so instead of using it, we had until recently a
locally hacked code based on an older version.  Today, we've gone back
to using giflib directly and libmagick is probably stable enough to
use as a replacement for our custom high-level code, but if you were
to try to use all of the various libraries proposed to replace core
Emacs functionality, some would be lemons and you'd take two steps
back for every step forward.

You can complain that "plugins" should be written in a more popular
language like Python or Visual BASIC<snort />, of course, but as
several others have pointed out, you would not be able to take
advantage of 3 decades worth of Lisp libraries in doing that, and
often the libraries available in Python or Ruby are more buggy because
much younger.

And if you look at what people who want a non-Emacs advanced editor
for their Python or Ruby projects do, they don't write it in Python or
Ruby.  (Yes, I know about IDLE, and it's not an advanced editor, nor
is it as easy to extend as Emacs.)  No, they go hack on vim!

As for browsing 1GB (well, for Emacs it would be 256MB, I guess?) log
files, there's nothing like (X)Emacs!