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 22:35:09 -0500 (CDT) Message-ID: <200505300335.j4U3Z9W13599@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> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117424431 4732 80.91.229.2 (30 May 2005 03:40:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 May 2005 03:40:31 +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 05:40:28 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dcb8L-0008O9-1k for ged-emacs-devel@m.gmane.org; Mon, 30 May 2005 05:40:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcbD8-0005Oo-2w for ged-emacs-devel@m.gmane.org; Sun, 29 May 2005 23:45:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DcbCX-00055p-VP for emacs-devel@gnu.org; Sun, 29 May 2005 23:44:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DcbCT-00053n-3K for emacs-devel@gnu.org; Sun, 29 May 2005 23:44:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcbCS-00052f-Qw for emacs-devel@gnu.org; Sun, 29 May 2005 23:44:24 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dcb5R-0007JW-RL; Sun, 29 May 2005 23:37:09 -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 j4U3ZdCK023408; Sun, 29 May 2005 22:35:39 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j4U3Z9W13599; Sun, 29 May 2005 22:35:09 -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:39 -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:37879 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37879 Maybe I could still use MODE-stored-mode as a define-global-minor-mode internal variable for efficiency reasons (unless it is easy to recognize whether we are running from a process or timer, in which case it is not necessary). That way, we are checking whether _after-change-major-mode-hook_ got the major mode correct. If it did, nothing could have messed it up later, since we are already in the final mode. Thus, post-command-hook does not need to dis- and re-enable the minor mode. This is what will happen in the vast majority of the cases. Otherwise, we dis- and re-enable. The trouble with doing that for Font Lock, given its current code, is what happens if after-change-major-mode never ran Font Lock, and Font Lock is nevertheless enabled. Then it was set by something else. Without help from Font Lock itself, we can not know whether that was for the correct major mode or not. This will happen infrequently enough that we do not need to worry about a small and unlikely inefficiency here. However, the trouble with the current Font Lock code is that trying to correct the major mode is a last resort desperation measure that may not work reliably, so we must be completely sure that it is really necessary. For Font Lock, we are not talking about a small inefficiency, but about real trouble. That would no longer be the case if dis- and re-enabling Font Lock reliably adapted it for the current mode. Sincerely, Luc.