From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: problem with mh-e and 2002-08-20 change to font-core.el Date: Mon, 26 Aug 2002 16:18:38 -0500 (CDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200208262118.QAA16553@eel.dms.auburn.edu> References: <200208260738.g7Q7c8S23362@localhost.localdomain> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1030396789 16085 127.0.0.1 (26 Aug 2002 21:19:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2002 21:19:49 +0000 (UTC) Cc: mh-e-devel@lists.sourceforge.net, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17jRH0-0004BA-00 for ; Mon, 26 Aug 2002 23:19:46 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jRm0-0006d0-00 for ; Mon, 26 Aug 2002 23:51:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jRIJ-0000pN-00; Mon, 26 Aug 2002 17:21:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jRG7-0000hI-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 17:18:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jRG4-0000gu-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 17:18:50 -0400 Original-Received: from manatee.dms.auburn.edu ([131.204.53.104]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jRG4-0000gm-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 17:18:48 -0400 Original-Received: from eel.dms.auburn.edu (eel.dms.auburn.edu [131.204.53.108]) by manatee.dms.auburn.edu (8.9.1a/8.9.1) with ESMTP id QAA06490; Mon, 26 Aug 2002 16:18:40 -0500 (CDT) Original-Received: (from teirllm@localhost) by eel.dms.auburn.edu (8.9.3+Sun/8.9.3) id QAA16553; Mon, 26 Aug 2002 16:18:38 -0500 (CDT) X-Authentication-Warning: eel.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: y@mit.edu In-Reply-To: <200208260738.g7Q7c8S23362@localhost.localdomain> (y@mit.edu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6932 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6932 Chad wrote: It seems that this change: 2002-08-20 Richard M. Stallman * 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.