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: Tue, 31 May 2005 10:44:45 -0500 (CDT) Message-ID: <200505311544.j4VFijq17680@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> <200505290157.j4T1vus10117@raven.dms.auburn.edu> <200505292354.j4TNsTE13354@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117554431 5331 80.91.229.2 (31 May 2005 15:47:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 May 2005 15:47:11 +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 Tue May 31 17:47:08 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dd8uh-00068z-1Q for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 17:44:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dd8zn-0002yi-UN for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 11:49:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dd8z7-0002wk-Fh for emacs-devel@gnu.org; Tue, 31 May 2005 11:48:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dd8z6-0002wG-IW for emacs-devel@gnu.org; Tue, 31 May 2005 11:48:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dd8z6-0002vA-7p for emacs-devel@gnu.org; Tue, 31 May 2005 11:48:52 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dd8xU-0004LE-PV; Tue, 31 May 2005 11:47:12 -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 j4VFjKCK029244; Tue, 31 May 2005 10:45:21 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j4VFijq17680; Tue, 31 May 2005 10:44:45 -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 Tue, 31 May 2005 00:18:14 -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:37946 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37946 Richard Stallman wrote: But it seems plausible to me that mode hook functions might call functions that call font-lock-add-keywords. Would that be a problem? I am not the Font Lock maintainer and I do not know every aspect of Font Lock. But, in as far as I understand things, if they pass a non-nil MODE argument everything is OK in as far as the problems we are discussing. Major modes, hook functions, or anything else can call font-lock-add-keywords with a non-nil MODE argument without creating any problems of the type we are discussing. But if anything, mode hooks, whatever, directly or indirectly calls font-lock-add-keywords with a nil MODE argument at any time during a major mode function, trouble could potentially result. Suppose we make font-lock-add-keywords with nil for MODE record its argument in some permanent buffer-local variable. Then changing the major mode and reenabling font-lock would use the same keywords previously added. That would also change the current behavior when changing a major mode interactively. Currently, it gets rid of these keywords. When changing modes interactively, the situation is thousands of times more likely to occur than when changing major modes inside a derived mode. Stefan does not seem to consider getting rid of these keywords to be a problem when changing modes interactively, although he does consider it a problem when it happens in a derived mode. Maybe there should be such a variable but it should not be permanent local. When modes change inside a derived mode, kill-all-local-variables is not called. It is only called when the very first mode function is called. An alternative would be to get rid of the mysterious "subtle problems due to the details of the implementation" mentioned in the following quote from `(elisp)Search-based Fontification': *Warning:* Only use a non-`nil' MODE argument when you use `font-lock-add-keywords' or `font-lock-remove-keywords' in your `.emacs' file. 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. Then we could say instead that a non-nil MODE argument should only be used in such a way that it could never be directly or indirectly called from a major mode. Sincerely, Luc.