* Steve Haflich
|    second, the undo list is a user feature, and should not have stuff like
|    this added to it.  ideally, the undo list should not affect process output
|    to a buffer, but this is on our to-do list.
| 
| This seems like an unsolvable algorithm to me.

that might actually be -- the problem is what to do when user input is
mingled with process output into the same buffer.  it is far from clear
what the _only_ solution to this problem should be.

|    well.  `undo-limit' (20000) and `undo-strong-limit' (30000) are the upper
|    limits to how much undo information is kept, in bytes.  see their
|    documentation.
| 
| I tried a quick test, and was surprised by the results.  I wrote a couple
| megabytes into a cl lisp listener buffer, then used delete-region to
| remove most of it.  I then made about ten small additional interactions
| with the lisp listener.  The theory was that the huge delete-region would
| have been flushed by the size limit on buffer-undo memory.  I then used
| the undo command repeatedly to undo back through the huge delete-region.
| To my surprise Emacs 19.34.2 was quite willing to reinstantiate all the
| deleted text, quite in excess of undo-strong-limit.

as their documentation say, these limits apply when garbage collection
happens.  garbage collection is a function of the amount of allocated bytes
of memory in Emacs Lisp, and is controlled by `gc-cons-threshold', which is
normally 400 000.  I would have thought a large deletion would require
consing up a huge string, thus triggering a garbage collection.

| I'm unsure whether you are actually suggesting that undo not be supported
| at all in a listener buffer.

no, undo is great for user input.  process output, however, should not be
put on the undo list.

| Alas, I suspect this is impractical without significant work.  Comint is
| nice, but the initial version of the acl emacs-lisp interface was coded
| in 1987 and would be hard to glue together the subsequent decade of
| independent developments.  I don't think anyone is prepared to do a full
| rewrite right now...

I'm sensitive to the problem of using new features in Emacs, but we don't
release a new Emacs all that often, and we're doing a pretty solid job of
documenting all changes in the ChangeLog and in the NEWS file.  the idea, I
think, was that programmers of packages would look at these and make each
change incrementally.  however, Emacs doesn't have all that brilliant ways
to identify versions, and portable code acquires versionitis and accretes
an enormous amount of code were it to make each change depend on the
version.  this is even acknowledged to be an unsolvable problem.

#\Erik