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

[martin rudalics]

> 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.