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: Thu, 26 May 2005 02:00:25 -0400 Message-ID: References: <87y8a3mnz8.fsf@xs4all.nl> <87ll63weye.fsf-monnier+emacs@gnu.org> <200505251624.j4PGOBF24551@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1117087227 28687 80.91.229.2 (26 May 2005 06:00:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 May 2005 06:00:27 +0000 (UTC) Cc: dominik@science.uva.nl, monnier@iro.umontreal.ca, Lute.Kamstra.lists@xs4all.nl, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 26 08:00:16 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DbBPh-0006We-Om for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 08:00:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbBTh-0006nh-LP for ged-emacs-devel@m.gmane.org; Thu, 26 May 2005 02:04:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DbBSk-0006mQ-Pt for emacs-devel@gnu.org; Thu, 26 May 2005 02:03:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DbBSj-0006lq-9R for emacs-devel@gnu.org; Thu, 26 May 2005 02:03:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbBSi-0006lT-Hr for emacs-devel@gnu.org; Thu, 26 May 2005 02:03:20 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DbBQj-00027i-0q for emacs-devel@gnu.org; Thu, 26 May 2005 02:01:17 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1DbBPt-00045k-Os; Thu, 26 May 2005 02:00:25 -0400 Original-To: Luc Teirlinck In-reply-to: <200505251624.j4PGOBF24551@raven.dms.auburn.edu> (message from Luc Teirlinck on Wed, 25 May 2005 11:24:12 -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:37668 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37668 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. 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. 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?