From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: org-mode and mode hooks. Date: Sun, 29 May 2005 19:42:08 -0500 (CDT) Message-ID: <200505300042.j4U0g8w13421@raven.dms.auburn.edu> References: <87y8a3mnz8.fsf@xs4all.nl> <87ll63weye.fsf-monnier+emacs@gnu.org> <200505252135.j4PLZvt26969@raven.dms.auburn.edu> <87hdgrufcl.fsf-monnier+emacs@gnu.org> <200505260359.j4Q3xbj28809@raven.dms.auburn.edu> <87is16rsid.fsf-monnier+emacs@gnu.org> <200505261501.j4QF17h00246@raven.dms.auburn.edu> <87psveq60w.fsf-monnier+emacs@gnu.org> <200505271717.j4RHHGD07067@raven.dms.auburn.edu> <200505290220.j4T2Kc010172@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117413928 16958 80.91.229.2 (30 May 2005 00:45:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 May 2005 00:45:28 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, mmaug@yahoo.com, Lute.Kamstra.lists@xs4all.nl, dominik@science.uva.nl Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 30 02:45:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DcYOt-0005mQ-S0 for ged-emacs-devel@m.gmane.org; Mon, 30 May 2005 02:45:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcYTg-0006Fj-6r for ged-emacs-devel@m.gmane.org; Sun, 29 May 2005 20:50:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DcYSX-0005t1-Tw for emacs-devel@gnu.org; Sun, 29 May 2005 20:48:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DcYSQ-0005my-Od for emacs-devel@gnu.org; Sun, 29 May 2005 20:48:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcYSO-0005ii-4c for emacs-devel@gnu.org; Sun, 29 May 2005 20:48:41 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DcYNz-00075u-5c; Sun, 29 May 2005 20:44:07 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j4U0gcCK022960; Sun, 29 May 2005 19:42:38 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j4U0g8w13421; Sun, 29 May 2005 19:42:08 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 29 May 2005 08:04:41 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37872 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37872 Richard Stallman wrote: It sounds like you are saying that with your patch, Font Lock mode still works wrong. Essentially, yes. It can only work correctly if all major modes not only adhere strictly to our new Emacs 22 conventions, but in addition carefully avoid anything that enables font-lock (other than through the define-global-minor-mode machinery) or that calls font-lock-{add,remove}-keywords, directly or indirectly. If so, that means this fix doesn't fix things. We need to figure out what to do about Font Lock mode. The _one_ big problem is that dis- and then re-enabling Font Lock is not sufficient to reliably adapt Font Lock for the current major mode if it has already been configured earlier in an ancestor mode. (In fact there seems to be currently _no way whatsoever_ to reliably correct a prior configuration for an ancestor mode.) Without this problem Font Lock does _not_ need to keep track of the major mode. In fact, even major modes that do not adhere to the new conventions no longer would present problems. I believe that it is definitely theoretically possible to redesign Font Lock in such a way that dis- and re-enabling it would configure reliably for the current major mode, even with prior misconfiguration. This would seem highly desirable. But it seems non-trivial and requires a much better knowledge of all the intricate details of Font Lock than I personally have. So somebody else would have to do it. If so, that means this fix doesn't fix things. We need to figure out what to do about Font Lock mode. Can you explain the problem with Font Lock mode that remains after your proposed patch? Stefan knows the Font Lock code better than I do. But if I understand things correctly (otherwise, Stefan can correct me) the problem is this excerpt from `(elisp)Search-based Fontification', talking about font-lock-{add,remove}-keywords: When you use these functions from a Lisp program (such as a minor mode), we recommend that you use `nil' for MODE (and place the call on a hook) to avoid subtle problems due to the details of the implementation. The problem is that if you call these functions with `nil' for MODE, this sets up Font Lock for the current major mode, which could be an ancestor mode (it calls font-lock-set-defaults). This problem also occurs if the ancestor mode enables font-lock-mode. But the problem with font-lock-add-keywords with `nil' for MODE is _way worse_. If all that happened was that font-lock-mode was enabled too soon, but without font-lock-{add,remove}-keywords being ever called, then I believe that my patch will reliably correct for the actual final major mode. But if font-lock-add-keywords was called with `nil' for MODE, my patch will undo the adding of the keyword. However, a `nil' argument means that the adding should be independent of the MODE, so we are in trouble. The only way out of this trouble, without non-trivial changes to Font Lock, is a convention that major modes should not directly or indirectly call font-lock-{add,remove}-keywords. I do not even know whether that convention would be reasonable. But even if we adopt that convention, we should hunt for modes that do not follow it and correct them, hence the error message. Sincerely, Luc.