Re: problem with mh-e and 2002-08-20 change to font-core.el

[Luc Teirlinck]

Chad wrote:

   It seems that this change:

   2002-08-20  Richard M. Stallman  <address@hidden>

           * font-core.el (font-lock-change-mode): New function.
           (font-lock-mode): Use font-lock-change-mode instead of
           font-lock-unfontify-buffer.
           (font-lock-maximum-size, font-lock-verbose): Add defvars.

   Causes a problem with mh-e (if the mh-show buffer enables font-lock,
   such as with global-font-lock-mode).  Specifically, this change causes
   any visited message buffer to be marked as modified when mh-e attempts
   to display the second (and subsequent) message in a folder, and so
   triggers mh-e's ``Message 920 modified; flush changes? (yes or no) ''
   behavior.  I've temporarily backed out this change in my local emacs to
   verify that the problem goes away.

   It seems that this change (removing the properties) is a good change,
   and I recall it being discussed on emacs-devel, but I only lightly
   skimmed the discussion, and I don't have any strong ideas about how to
   resolve this conflict.

   chad

I believe that the fundamental problem underlying this is that
changing text properties marks the buffer as being changed.  From a
"philosophical" perspective, this actually makes sense since text
properties are considered part of the text.  From a practical
perspective (which, in my opinion, is the only really relevant
perspective) however, it leads to very strange behavior.  This was
already true before Richard's change.  All Richard's change did was
provide some additional instances of such strange behavior.

Do:

emacs-21.3.50 -q --eval '(blink-cursor-mode 0)'

(The last command line argument has nothing to do with the problem,
but it prevents serious damage to the nervous system.)

Visit some file in fundamental-mode.  (The last specification is
probably irrelevant.)

Do:

M-: (put-text-property 1 10 'face '((:background "orange")))

The buffer is now modified.

First inconsistency: Do:

M-x revert-buffer

The buffer is now marked unmodified, but the orange background is
still there.

Redo:

M-: (put-text-property 1 10 'face '((:background "orange")))

This is not redundant (although I personally believe it should be),
the buffer is once again considered modified.

C-x C-c.

We get amply warned about the changed buffer.

Ignore all warnings and exit, without "saving" the buffer.

Start Emacs again and visit the file again.  There reportedly are
saved changes which we should consider recovering. There is indeed an
auto-save file, but diff shows it is identical to the actual file.
Moreover, there is no trace of the orange background.

All of this behavior actually would make sense if text properties were
saved to file.  For instance, in that case revert-buffer would erase
the orange background.

However, write-region-annotate-functions is still nil and
after-insert-file-functions only contains
after-insert-file-set-buffer-file-coding-system, which, in as far has
I can tell, has nothing to do with saving and restoring text
properties.  If text properties would be saved to file, then maybe
the behavior reported by Chad would no longer be a bug either.  (I can
not tell, since I do not use mh-e.)

Is somebody actually working on saving text properties to file?
Would such a feature be optional or non-optional?

Sincerely,

Luc.