Re: [R.Ekker@ai.rug.nl: highlight-changes-rotate-faces sets buffer modified flag]

[martin rudalics <rudalics@gmx.at>]

 >      > Should it use something the font-lock mechanism so that it can update
 >      > when the buffer is edited?
 >
 >     Hmmm ... it does so, in principle, but for the reliance on the undo
 >     mechanism.
 >
 > I don't understand that -- can you explain?

`hilit-chg-set-face-on-change' operates pretty much like the font-lock
after-change mechanism:

If the change _is not_ caused by an undo it assigns the text-property
hilit-chg to the changed text and calls `hilit-chg-fixup' which installs
the overlays necessary for highlighting the changed text in accordance
with the just assigned text-property.

If the change _is_ caused by an undo, `hilit-chg-set-face-on-change'
falls back on the undo mechanism to restore the hilit-chg
text-properties and calls `hilit-chg-fixup' as in the non-undo case.

font-lock (usually) calculates the text properties anew after every
buffer change for the changed region regardless of whether they are
caused by an undo or not.  The idea of using undo for restoring text
(and subsequently overlay) properties strikes me as both clever and
elegant.  It makes it tricky though to keep the buffer-modified state
congruent as I explained in another mail: "face rotations" must show up
in buffer-undo-list but should not mark the buffer as modified.  This is
no problem as long as I'm able to hide rotations from the user, for
example, by running them in a hook which resets the modified flag
anyway.  It is a problem when the hook or function does not set the
modified-flag.  Hence, undoing a rotation may set the modified flag
although no user initiated buffer-change occurred.  If there were a
buffer-undo-list entry type which wouldn't set the modified flag ...