From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: Calling another major mode in a major mode body Date: Tue, 22 Nov 2022 13:44:07 +1300 Message-ID: References: <1263D369-330F-4624-A376-ECC1E1A26A52@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16099"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Orcon Webmail Cc: emacs-devel To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 22 01:44:55 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxHPD-0003ww-B4 for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Nov 2022 01:44:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxHOd-0000sQ-4J; Mon, 21 Nov 2022 19:44:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxHOb-0000sF-FV for emacs-devel@gnu.org; Mon, 21 Nov 2022 19:44:17 -0500 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxHOZ-0007JP-Nm for emacs-devel@gnu.org; Mon, 21 Nov 2022 19:44:17 -0500 Original-Received: from [10.253.37.70] (port=49223 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1oxHOR-0003kD-Fl; Tue, 22 Nov 2022 13:44:07 +1300 Original-Received: from ip-180-148-114-34.kinect.net.nz ([180.148.114.34]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Tue, 22 Nov 2022 13:44:07 +1300 In-Reply-To: <1263D369-330F-4624-A376-ECC1E1A26A52@gmail.com> X-Sender: psainty@orcon.net.nz X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.59; envelope-from=psainty@orcon.net.nz; helo=smtp-4.orcon.net.nz X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300318 Archived-At: On 2022-11-22 11:07, Yuan Fu wrote: > So I wonder if it’s ok to fall back to another major mode by simply > calling that mode. I think the following describes what that would do. Quoting myself from https://stackoverflow.com/a/19295380 (and as a tangent I'd be happy for some adaptation of that to live somewhere in the elisp manual, as I think it was a decent explanation of the processes), when we call `child-mode', the full sequence is: (run-hooks 'change-major-mode-hook) ;; actually the first thing done by (kill-all-local-variables) ;; <-- this function ,@grandparent-body ,@parent-body ,@child-body (run-hooks 'change-major-mode-after-body-hook) (run-hooks 'grandparent-mode-hook) (run-hooks 'parent-mode-hook) (run-hooks 'child-mode-hook) (run-hooks 'after-change-major-mode-hook) ;; plus the following final step, since: ;; commit 2eb6817ba971184cc109f8530f4b3b38f65650ea ;; Add :after-hook facility to define-derived-mode. (run-hooks delayed-after-hook-functions) `delay-mode-hooks' is still in effect until child-body has returned, so I believe calling (fallback-mode) within child-body would result in this sequence: (run-hooks 'change-major-mode-hook) ;; actually the first thing done by (kill-all-local-variables) ;; <-- this function ,@grandparent-body ,@parent-body ,@child-body + (run-hooks 'change-major-mode-hook) ;; actually the first thing done by + (kill-all-local-variables) ;; <-- this function + ,@fallback-parent-mode-body + ,@fallback-mode-body ;; The child-mode binding for `delay-mode-hooks' is now out of scope, ;; so `run-mode-hooks' finally acts... (run-hooks 'change-major-mode-after-body-hook) (run-hooks 'grandparent-mode-hook) (run-hooks 'parent-mode-hook) (run-hooks 'child-mode-hook) + (run-hooks 'fallback-parent-mode-hook) + (run-hooks 'fallback-mode-hook) (run-hooks 'after-change-major-mode-hook) (run-hooks delayed-after-hook-functions) It looks like things pushed onto `delayed-after-hook-functions' would happen in this sequence, though: - grandparent-mode - parent-mode - fallback-parent-mode - fallback-mode - child-mode Although `delayed-after-hook-functions' does not seem to be permanent-local, so in fact it might be this? - fallback-parent-mode - fallback-mode - child-mode There's also this, which doesn't seem entirely appropriate, but... ** New functions 'major-mode-suspend' and 'major-mode-restore' Used when switching temporarily to another major mode, e.g. for hexl-mode, or to switch between c-mode and image-mode in XPM.