From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: org-mode and mode hooks. Date: Tue, 31 May 2005 15:08:48 -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> <200505311544.j4VFijq17680@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1117566774 19373 80.91.229.2 (31 May 2005 19:12:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 May 2005 19:12:54 +0000 (UTC) Cc: mmaug@yahoo.com, emacs-devel@gnu.org, rms@gnu.org, 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 21:12:52 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DdC9M-0004m9-CI for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 21:11:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdCEV-0000iG-5g for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 15:16:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DdCCI-00088C-PG for emacs-devel@gnu.org; Tue, 31 May 2005 15:14:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DdCCC-00082q-Jd for emacs-devel@gnu.org; Tue, 31 May 2005 15:14:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdCC8-0007u9-LZ for emacs-devel@gnu.org; Tue, 31 May 2005 15:14:35 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DdC8T-0004Jr-FT; Tue, 31 May 2005 15:10:45 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 6B9A82CF427; Tue, 31 May 2005 15:08:52 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 9D71F4AC179; Tue, 31 May 2005 15:08:47 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A8986506C; Tue, 31 May 2005 15:08:48 -0400 (EDT) Original-To: Luc Teirlinck In-Reply-To: <200505311544.j4VFijq17680@raven.dms.auburn.edu> (Luc Teirlinck's message of "Tue, 31 May 2005 10:44:45 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.841, requis 5, autolearn=not spam, AWL 0.06, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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:37963 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37963 > 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. Problem is that some of those keywords should be permanent and others shouldn't. E.g. it depends whether they correspond to a minor mode which is permanent or not. > 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 The assumption is that those keywords are added via a function placed on the major mode's hook, i.e. the keywords tweak the major mode and should thus be removed/readded when the major mode changes. Of course in other settings it should behave differently. The problem is that the API is too simplistic. Stefan