From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: org-mode and mode hooks. Date: Thu, 26 May 2005 12:31:02 +0200 Message-ID: <87hdgql1nd.fsf@xs4all.nl> References: <87y8a3mnz8.fsf@xs4all.nl> <87ll63weye.fsf-monnier+emacs@gnu.org> <200505251624.j4PGOBF24551@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 1117104289 9318 80.91.229.2 (26 May 2005 10:44:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 May 2005 10:44:49 +0000 (UTC) Cc: dominik@science.uva.nl, Luc Teirlinck , monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 26 12:44:38 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DbFqA-0001A5-Sp for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 12:43:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbFuD-0001DO-LF for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 06:48:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DbFjM-0006b5-FN for emacs-devel@gnu.org; Thu, 26 May 2005 06:36:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DbFjG-0006YJ-H9 for emacs-devel@gnu.org; Thu, 26 May 2005 06:36:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbFjF-0006X0-MS for emacs-devel@gnu.org; Thu, 26 May 2005 06:36:41 -0400 Original-Received: from [194.109.24.21] (helo=smtp-vbr1.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DbFeS-0006zG-14; Thu, 26 May 2005 06:31:44 -0400 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id j4QAV3q8077173; Thu, 26 May 2005 12:31:03 +0200 (CEST) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1DbFdm-00028R-00; Thu, 26 May 2005 12:31:02 +0200 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Thu, 26 May 2005 02:00:25 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 56 X-Virus-Scanned: by XS4ALL Virus Scanner 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:37690 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37690 Richard Stallman writes: > I believe that we plan to eventually make all modes run > `after-change-major-mode-hook', usually as a byproduct of making them > run their mode hook with `run-mode-hooks'. > > If there are any major modes that fail to use run-mode-hooks, we want > to fix them now. It would be good for someone to look for them. I'll do that. > However, users also have major modes, and we probably cannot expect > all of them to be changed for many years. So it will not be possible > to absolutely rely on all major modes to run after-change-major-mode-hook > at the end. Features that depend on this will fail to work in those > user-defined major modes that have not been updated. > > In some cases that will not be a real problem. When it is ok to say, > "Your major mode has a bug and needs to be corrected," we can say it. > For instance, if a global minor mode doesn't turn on in the user's > major mode because of this, we can respond that way. > > However, when a feature really needs to be reliable, it should not use > after-change-major-mode-hook now or for the next few years. I will > document that in the manual. > > I do not know whether there are a lot of derived modes that do not > follow the convention. The most satisfactory solution would obviously > be to make them all follow the conventions. If this would be > unrealistic, possibilities include to come up with a better fallback > alternative or to simply revert my change. > > If the change provides advantages, we have no reason to revert it. > What is the worst thing that can happen when a derived mode fails to > run after-change-major-mode-hook? Only that it won't enable certain > global minor modes. Font Lock mode is an example of such a global minor mode. My guess is that over 90% of Emacs' users enable global-font-lock-mode. It's pretty bad if enabling that breaks for some modes. > If that bothers the user, he can fix his derived mode to follow the > latest conventions. > > However, if we can easily make global minor modes work more reliably, > we may as well do so. Perhaps by using find-file-hook *as well as* > after-change-major-mode-hook. Why not? That solves the problem that global minor modes are not enabled for major modes that do not use run-mode-hooks. However, it doesn't solve the problem that a global minor mode is enabled *too soon* because a derived major mode doesn't delay the running of hooks of its parent mode. (Note: derived modes defined with define-derived-mode always delay the running of hooks.) Lute.