From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#35351: 27.0.50; Enable derived modes to run their own very-early 'change-major-mode-hook' code Date: Mon, 22 Apr 2019 20:16:33 +1200 Message-ID: <7db75b50-1925-8c1e-acc5-c393b701e6a3@orcon.net.nz> References: <85237c18-768d-089b-221a-fe70b0ba4379@orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="35424"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 To: Stefan Monnier , 35351@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 22 10:17:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hIU8Z-000957-Uz for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2019 10:17:16 +0200 Original-Received: from localhost ([127.0.0.1]:34066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIU8Y-0007Ct-RW for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Apr 2019 04:17:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIU8R-0007CV-49 for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 04:17:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIU8O-000116-Vu for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 04:17:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36112) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hIU8M-000109-22 for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 04:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hIU8L-00039y-P8 for bug-gnu-emacs@gnu.org; Mon, 22 Apr 2019 04:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Apr 2019 08:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35351 X-GNU-PR-Package: emacs Original-Received: via spool by 35351-submit@debbugs.gnu.org id=B35351.155592100112116 (code B ref 35351); Mon, 22 Apr 2019 08:17:01 +0000 Original-Received: (at 35351) by debbugs.gnu.org; 22 Apr 2019 08:16:41 +0000 Original-Received: from localhost ([127.0.0.1]:49656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIU81-00039L-Ak for submit@debbugs.gnu.org; Mon, 22 Apr 2019 04:16:41 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:60118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIU7y-00039C-DN for 35351@debbugs.gnu.org; Mon, 22 Apr 2019 04:16:39 -0400 Original-Received: from [150.107.172.17] (port=44713 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1hIU7t-0000rE-L1; Mon, 22 Apr 2019 20:16:34 +1200 In-Reply-To: Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157991 Archived-At: On 22/04/19 8:54 AM, Stefan Monnier wrote: > Usually this is done with something akin to: > (define-derived-mode my-actual-mode > ...) > (defun my-mode () > (my-save-local-vars) > (my-actual-mode)) > > or something similar (or not using define-derived-mode). > Of course, this comes with its own drawbacks. Yes, I think I like that least of all -- having the macro set up everything based on a different name to the mode that people are expected to be using just seems wrong to me. I'd say the fact that there's a known "usual" hack for this suggests that there's good reason to implement it directly in the macro. > Indeed what you're asking for is like a :before-hook symmetric I've pushed an implementation to branch origin/fix/bug-35351 as a starter. https://git.savannah.gnu.org/cgit/emacs.git/log?h=fix/bug-35351 Previous Emacs versions will ignore the unrecognised keyword and its value; so libraries using the new keyword and still wanting to support older versions of Emacs can safely use the new keyword and *conditionally* add advice when the Emacs version is < 27, to run the same code before the mode function and achieve the same effect. > (FWIW, I think the "-hook" part of the name was probably not > the best choice). I've used the name :before-hook to match the existing :after-hook, but we can certainly change it to something else. (We could potentially deprecate the name :after-hook as well, and add an alias for that with a better name at the same time.) I'm now unsure whether :after-hook was intended to be interpreted as "this is a bit like a *hook* which runs *after* everything else has happened"; or if it meant "do this thing *after* the mode *hook*" (or indeed after after-change-major-mode-hook). The name ":before-hook" only really matches the former interpretation. ("before the mode hook" would be more change-major-mode-after-body-hook than change-major-mode-hook). Would :eval-before and :eval-after be good? It might also be nice if symbol values for these keywords were interpreted as the name of a function to call. I don't think that change would be *expected* to break anything, as a symbol value would in effect be a no-op for the current :after-hook, and so I wouldn't expect any existing modes to be using a symbol value. In the initial commit I've used an approach which will run the parent's :before-hook before the child's :before-hook, using the change-major-mode-hook technique I mentioned at the end of my original message, although I'm still uncertain about which order is *best*. Possibly it should be child-before-parent on the basis that the author then has more influence over the order in which things happen? i.e.: If we implement it like this: ,child-before-hook (delay-mode-hooks (,(or parent 'kill-all-local-variables)) Which gives us the sequence: child-before-hook parent-before-hook change-major-mode-hook Then child-before-hook could, if it wanted, do this: (add-hook 'change-major-mode-hook FOO nil :local) And then FOO would run *after* the parent-before-hook, effectively reversing that sequence. (Whereas the code I've pushed initially is already using that change-major-mode-hook approach, so there's no scope to manipulate the order.) Child-before-parent also means :before-hook *really is* the very first thing that happens in the child mode, just as :after-hook is the very last; so perhaps that's still a good/intuitive way around, even if it's the reverse of the parent->child order used in all the other phases of the mode's execution. Child-before-parent would also match the order when 'before' advice was being used to mimic the :before-hook behaviour in older versions of Emacs. I'm not sure I have a strong opinion on the matter, and the cases in which it would even matter would be limited, but I think I've now argued myself around to being slightly in favour of child- before-parent; so if no one else has strong feelings about it, I'll most likely change it to that. -Phil