From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: org-mode and mode hooks. Date: Tue, 31 May 2005 00:18:14 -0400 Message-ID: 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> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117513512 12682 80.91.229.2 (31 May 2005 04:25:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 May 2005 04:25:12 +0000 (UTC) Cc: Lute.Kamstra.lists@xs4all.nl, dominik@science.uva.nl, mmaug@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 31 06:25:01 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DcyIn-0002Nf-CP for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 06:24:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcyNo-0000AR-6X for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 00:29:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DcyKZ-00078j-IS for emacs-devel@gnu.org; Tue, 31 May 2005 00:26:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DcyKT-00073f-Fy for emacs-devel@gnu.org; Tue, 31 May 2005 00:26:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcyKP-00070l-9k for emacs-devel@gnu.org; Tue, 31 May 2005 00:26:09 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DcyFC-00052W-QT for emacs-devel@gnu.org; Tue, 31 May 2005 00:20:46 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1DcyCk-0005zE-6F; Tue, 31 May 2005 00:18:14 -0400 Original-To: Luc Teirlinck In-reply-to: <200505292354.j4TNsTE13354@raven.dms.auburn.edu> (message from Luc Teirlinck on Sun, 29 May 2005 18:54:29 -0500 (CDT)) 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:37922 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37922 Major modes should follow the conventions for major modes rigorously. But, in addition, they should not enable Font Lock in any way, directly or indirectly (other than through the define-global-minor-mode machinery), and they also should not call font-lock-add-keywords directly or indirectly, even if this does not enable Font Lock. I just looked for all the calls to font-lock-add-keywords in Emacs. In no case does any major mode call font-lock-add-keywords directly, or even fairly directly. But it seems plausible to me that mode hook functions might call functions that call font-lock-add-keywords. Would that be a problem? comint-mode and interactive-sql-mode both enable Font Lock (the latter via sql-product-font-lock), creating problems for modes derived from them. I think it would be more consistent, nowadays, to turn that off. Anyway, how about if we change define-minor-mode so that it generates the code to record which major mode enabled it? The very vast majority of minor modes have no reason whatsoever to do this. Does that matter? If only a few of them need to do this, perhaps it is better to do this automatically in all the minor modes (even though it is unnecessary in most of them) than to make users do it manually and risk bugs. The only known example (and hopefully the only example, period) is Font Lock mode. If these complexities apply only to Font Lock mode, perhaps we don't need to document them in the doc string of define-global-minor-mode. I will propose a new patch to easy-mmode that does _not_ use the new variable MODE-stored-mode. It will say that dis- and then re-enabling the minor mode should correctly set up the minor mode for the current major mode. Ok, but... The only trouble with that is that this condition does not apply to Font Lock. if the problem exists only for Font Lock mode, and your proposed solution does not solve it for Font Lock mode, what problem is this solution solving? 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). I don't understand. How can the current major mode "be" an ancestor mode? Do you mean that the font-lock settings came from an ancestor mode? But if font-lock-add-keywords was called with `nil' for MODE, my patch will undo the adding of the keyword. 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. It's possible this would do something wrong in certain other cases, but would it do the right thing in these cases? Note that even after this patch, there is one potentially troublesome case left. It concerns the case of a major mode that gets enabled by a timer or process for a non-file visiting buffer. Would you please explain what problem would happen in this case? It is hard to understand your arguments about proposed solutions when you haven't said what the problem is. (Even in this case it is only likely to occur for major modes that do not follow the new conventions.) In that case, maybe it is a fine solution to tell people to fix their major modes. Why go to a lot of trouble about broken major modes? 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. What kind of something else could it be? One possibility is that the major mode itself turned on font-lock mode. You've said that there's a problem when a major mode turns on font-lock mode. Aside from that, what other case could do that? Anyway, please explain why you think it is difficult for turning font lock off and on again to give the right results. Can my proposed change to font-lock-add-keywords work? If not, why not?