Re: A new(?) warning of erase-buffer, which was not seen before.

[martin rudalics <rudalics@gmx.at>]

 > In the case of comint, I'd actually like to try supporting a model where
 > the undo-list-updating is _not_ handled directly by the text modifying
 > code -- i.e. `insert/delete-without-undo' wouldn't work.  The reason is
 > that some text modification is done by various hook functions in comint,
 > and those are harder to control (e.g. they may be written by the user).
 >
 > I don't think this is too much of a problem given the restrictions of
 > comint mode (where non-undoable and undoable modifications are separated
 > by a clear boundary).

Agreed.

 > To support this model in a more general manner I guess would require
 > primitive support (e.g., something like an `inhibit-undo' variable which
 > would cause primitives to adjust the undo list instead of recording undo
 > information).

I think it's not feasible.  I tried to write such code for customization
buffers - where undo can erase entire buffer contents - but didn't get
very far.  It should be possible though since these undos have "clear
boundaries" as for the comint case (hence you could try to have a look
at this - maybe you come up with a solution that works for both).  A
general solution would virtually have to undo every single action on the
undo list to check how a current non-undoable modification interferes
with undoable ones.