Re: undo weirdness with insert-file-contents

[Stefan Monnier]

> I always wondered whether the REPLACE thingy could have been implemented
> easier by comparing the region around `point' before and after the
> replacement.  Many routines apply such heuristics (bookmarks, etags,
> diff related programs).

See my wishlist item in the emacsbugs page ;-)

>>> A second reason stems from the various decoding steps.  Ideally,
>>> decoding should run transparently and only the "final" insertion get
>>> recorded.  For this purpose you have to temporarily switch off undo
>>> recording in the non-visiting case.  Otherwise, undoing changes could
>>> reveal changes done by the decoding routine as can be observed with
>>> Emacs 22.  Moreover, recording changes during decoding might be
>>> expensive.
>> 
>> I understand this part, but it seems there's got to be a simpler way.
>> 
>> BTW, rather than use an undo-boundary, we could simply store the old
>> undo-list in some local var, then set undo-list to nil, then do the
>> dance,

> ... dancing with undo enabled?

>> then nconc the new undo-list and the old undo-list.  Setting the
>> undo-list to nil temporarily hides the previous undo-list, thus
>> preventing merging entries.

> But _all_ we really need are the beginning and end of the inserted text.
> We can get them easily with undo recording turned off during decoding -
> once the problems with VISIT and REPLACE have been resolved.

Good, point so we just turn off undo during the dance and then insert
the single undo-element (this is only valid for non-REPLACE, of course).

>> Or rather create a new insert-file-contents-1 which doesn't take any
>> `visit' argument.

> ... but a REPLACE argument, I suppose.  See the example with BEG and
> REALBEG above: Undo from BEG or REALBEG?

The undo-list should record the finer description of the change.


        Stefan