From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: problem with mh-e and 2002-08-20 change to font-core.el Date: Thu, 29 Aug 2002 11:25:42 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200208291525.g7TFPgG10906@rum.cs.yale.edu> References: <200208260738.g7Q7c8S23362@localhost.localdomain> <200208262151.g7QLpN812743@wijiji.santafe.edu> <200208262209.g7QM9cx26500@rum.cs.yale.edu> <200208280653.g7S6r4p13393@wijiji.santafe.edu> <200208281355.g7SDtUl03773@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030634935 4656 127.0.0.1 (29 Aug 2002 15:28:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 15:28:55 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, y@mit.edu, 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 17kRE1-0001Cj-00 for ; Thu, 29 Aug 2002 17:28:49 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17kRkL-0007f8-00 for ; Thu, 29 Aug 2002 18:02:13 +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 17kRFN-0001da-00; Thu, 29 Aug 2002 11:30:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kRC6-0001YE-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 11:26:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kRBu-0001XM-00 for emacs-devel@gnu.org; Thu, 29 Aug 2002 11:26:49 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17kRBg-0001St-00; Thu, 29 Aug 2002 11:26:27 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g7TFPgG10906; Thu, 29 Aug 2002 11:25:42 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Richard Stallman 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:7116 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7116 > > That would not do the job; it would fail to remove all the properties > > which the current code removes. > > Can you give examples ? > > Modes that use font-lock-face are an example. The current code > removes that property; just turning off font-lock-mode would not > remove it. > > font-lock-face properties go in mode-specific places. But do the properties belong to the text or to the mode. I have the impression that most of those font-lock-face properties are added together with the corresponding text and that they can't be recovered just from the text. I.e. erasing them might not be the right thing to do since it loses information. > PS: And the current code fails to remove those properties if you didn't > turn font-lock-mode ON, which doesn't make much sense either. > > Sorry, I don't understand. Would you say that more clearly? The "erase the font-lock-face property when changing-mode" hook you added is only added when you turn on font-lock-mode, so the font-lock-face property will stay if you don't turn on font-lock-mode before changing major-mode. Examples: emacs -q --no-site-file M-x ibuffer M-x text-mode M-: (ibuffer-mode) M-x font-lock-mode you see the font-locked text. Now try this instead: emacs -q --no-site-file M-x ibuffer M-x font-lock-mode M-x text-mode M-: (ibuffer-mode) M-x font-lock-mode now you don't see any fontification. I actually think that the first behavior is more correct and corresponds to what happens if you call (font-lock-mode -1) instead of forcefully erasing the font-lock-face property. Stefan PS: The elisp manual clearly says in the "major mode conventions" node to "Define a command whose name ends in `-mode'" so ibuffer-mode should be interactive. I'd of course argue that it should use `define-derived-mode' which would have made it interactive as a matter of course without the programmer having to think about it. As long as we don't use such a macro systematically, we'll have to live with all those inconsistencies.