I wrote:
: Another approach to limiting a buffer's size is to define a minor mode 
: that does such by adjoining a trim-function to after-change-functions.
: 
: This does not require any process-output hooks; indeed it should work
: for buffers in most any major mode.

"Kenneth D. Forbus" <ils.nwu.edu at forbus> replied:
| 
| Making poor emacs do this seems like a horrible kludge.  Wouldn't a
| single-item-list dialog of fixed length, serviced as a ring buffer, work
| better for this particular application?  On Unix platforms this would rely
| on the long-awaited merge of Common Graphics with that software, but this
| would work on the Windows software today.

Eh? "Poor emacs" has a much more powerful extension language than
most any GUI you might desire to integrate it with, so the natural
approach should be to exploit the extension language (e-lisp) as
it was meant, implementing the desired buffer-trimming functionality
using one of the prior-mentioned e-lisp approaches.

I can't imagine why you think that providing some new low-level
widget is better when an entirely satisfactory solution is already
available in e-lisp. One should resort to low-level widgets and C
code only when there are damn good reasons (e.g. performance),
since they don't integrate well with the rest of emacs (e.g. you
can't extend them with 'advise', you can't easily debug them, etc).

Further, keep in mind that the ACL process is running inside a
*buffer*, and there may be very good reasons for having the output
log be a buffer (vs. some low-level GUI widget), e.g. the output
logged to the buffer might contain active Lisp s-exps (for use
in debugging, etc), which need to be parsed in Lisp mode (with
correct syntax, highlighting, etc), so that replacing the buffer 
by a GUI widget might result in a tremendous loss of power. Emacs
depends heavily upon all its objects being built atop the basic
buffer abstraction (what with its nonexistent OOP capabilities).

One of the primary reasons that XEmacs evolved much more quickly
than Emacs was due to the fact that many gratuitously coded C
modules were moved up to e-lisp where they belonged, and where it
was then much easier to extend them. Reversing this trend would
be a grave error.

-Bill Dubuque