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: Sat, 28 May 2005 20:57:56 -0500 (CDT) Message-ID: <200505290157.j4T1vus10117@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> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117331887 5968 80.91.229.2 (29 May 2005 01:58:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 29 May 2005 01:58:07 +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 Sun May 29 03:58:03 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DcD3X-000657-1H for ged-emacs-devel@m.gmane.org; Sun, 29 May 2005 03:57:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcD87-0007Rw-A2 for ged-emacs-devel@m.gmane.org; Sat, 28 May 2005 22:02:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DcD7e-0007Pn-Gg for emacs-devel@gnu.org; Sat, 28 May 2005 22:01:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DcD7d-0007PG-GL for emacs-devel@gnu.org; Sat, 28 May 2005 22:01:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcD7d-0007PC-D2 for emacs-devel@gnu.org; Sat, 28 May 2005 22:01:49 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DcD6M-0004Aj-7a; Sat, 28 May 2005 22:00:30 -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 j4T1wXCK018835; Sat, 28 May 2005 20:58:33 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j4T1vus10117; Sat, 28 May 2005 20:57:56 -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 Sat, 28 May 2005 07:53:25 -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:37839 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37839 Richard Stallman wrote: The reference "the function that does the initial set-up" is not concrete. I am not completely sure which function you mean. It would be better to refer to it by name. In the latest version of the patch I am going to send soon, it just says that enabling the mode in any way should set the variable. The author of the minor mode can decide on the details of how to do that. If this function is one that the user has to supply and define, then I ask: why make the user arrange to set MODE-stored-mode? Why not have define-global-minor-mode automatically arrange to save the value in that variable? Because we have to know in which major mode the minor mode was enabled. That could easily happen behind define-global-minor-mode's back, by using the non-global variant. In effect, we know of at least two examples of major modes that do this, comint-mode and interactive-sql-mode. There probably are others. They should not be doing that, but we want to be able to catch modes that do this. Also, if the user does something like (add-hook 'foo-mode-hook 'turn-on-font-lock), and then tries out global-font-lock-mode, trouble results for major modes derived in a non-standard way from foo-mode. Looking at your patch, it looks like this mechanism already is taken care of by code that is generated by define-global-minor-mode. Only partially. Sincerely, Luc.