From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Calling another major mode in a major mode body Date: Tue, 22 Nov 2022 18:03:43 -0800 Message-ID: References: <1263D369-330F-4624-A376-ECC1E1A26A52@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29480"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 03:04:38 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 1oxf7t-0007PX-JU for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 03:04:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxf78-00024a-N8; Tue, 22 Nov 2022 21:03:50 -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 1oxf76-00021s-Ns for emacs-devel@gnu.org; Tue, 22 Nov 2022 21:03:48 -0500 Original-Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxf74-0005vk-Sj for emacs-devel@gnu.org; Tue, 22 Nov 2022 21:03:48 -0500 Original-Received: by mail-pf1-x436.google.com with SMTP id 140so16056325pfz.6 for ; Tue, 22 Nov 2022 18:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BOgStQV52eQkAsLiJvbv7vtdBybBhcdr1+bignm7G0c=; b=dv9CQ7wQT2RwPtQFj4yitqbT9y3i93UxM3nZBZ03uquA+4nXWcl6OuKW4ejxHKej8j LUohA0BIyNJvpA7f46PyMqjjSSl9biLPj0YBN26w2KEwBDYdtmFf9UR6xPB1BK7zTn51 /lAD15IOn3BXHuwVazjlgh2Uv9BBWkqp0w1HnzKQP1v9mrWcahycc54B5AnTue0Ez7T2 6AHWuYk6dXJ9qo/0377DHo9Xdd7GWM+KsNGfwu7ygQLNjKjV+vYiIr06FdMso1ScAomL cRGX8Jc5HWL273DTieUOradqKye3+AIzykRHvfJ3vk+C/qddiG+0w6EX8+PHZU033020 qFoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BOgStQV52eQkAsLiJvbv7vtdBybBhcdr1+bignm7G0c=; b=eWvdewX2Zb+JNbxg99rOuWJgWESxjj9gjoE92t/tqyOXxivyxcMLIfJmYI+oJqZNkH b0qpHwFkHXdQAdTMON+tI86Pi3dnQW+c42eAuyc9hnI09zF+A9UqHMjHhU73eOU7+jUJ ib+Fj2nPF3QLK2R972UYUglW2HVPKZgpyREBD7YTvmaHwL/V1yAV4TYxRptQp8+2y6Yn TFevbZZfK7XeX+8VyXImkyV2xICPqyIOp96cDmfs8wNYN5bfTDHwlwmHc438odbhnDOE L2TOq0Tr3MFjfCcStVC5OibSC/nGMLk/cQM4RYW9AkFTMzw5yTyymJmpJ1ZEXyshh8ja iAKg== X-Gm-Message-State: ANoB5pnyP5SbfEH32bBzMGVmkBw8bKrqV7daVj0QYa1hjkJq0ldK9Tji 8MHt2WgWK8Q2m3YzrduR/IOTeSTn+x0rfQ== X-Google-Smtp-Source: AA0mqf4GjgV/L4p+S2shBKMsSYHxAZaxpTX7TvWLS67Yqj5QZnNDFtXT6ZA/V1CIU/7j6vsgcLX1Lw== X-Received: by 2002:a63:5409:0:b0:476:e3bb:2340 with SMTP id i9-20020a635409000000b00476e3bb2340mr5606326pgb.530.1669169025232; Tue, 22 Nov 2022 18:03:45 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id l23-20020a63f317000000b0046f1e8cb30dsm9780126pgh.26.2022.11.22.18.03.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2022 18:03:44 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=casouri@gmail.com; helo=mail-pf1-x436.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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:300371 Archived-At: > On Nov 21, 2022, at 4:44 PM, Phil Sainty wrote: >=20 > On 2022-11-22 11:07, Yuan Fu wrote: >> So I wonder if it=E2=80=99s ok to fall back to another major mode by = simply >> calling that mode. >=20 > I think the following describes what that would do. >=20 >=20 > 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: >=20 > (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) >=20 >=20 > `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: >=20 >=20 > (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) >=20 >=20 > It looks like things pushed onto `delayed-after-hook-functions' > would happen in this sequence, though: >=20 > - grandparent-mode > - parent-mode > - fallback-parent-mode > - fallback-mode > - child-mode >=20 > Although `delayed-after-hook-functions' does not seem to be > permanent-local, so in fact it might be this? >=20 > - fallback-parent-mode > - fallback-mode > - child-mode Thanks for that detailed explanation :-) It seems the current mode=E2=80=99s after-hook is ran the very last. So = it might be a good place to call the fallback major mode. The call to = run-hooks in a major mode invocation command is outside the scope = delay-mode-hooks, so simply calling the fallback major mode should be = fine? IMO, the sequence would be - parent-mode - child-mode - parent-hook - child-hook - parent-after-hook - child-after-hook: calls fallback-mode - fallback-parent ... Yuan=