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:15:09 -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="4688"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel , Stefan Monnier To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 03:16:15 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 1oxfJ8-00010G-Kj for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 03:16:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxfIK-0005Np-TU; Tue, 22 Nov 2022 21:15:24 -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 1oxfII-0005NA-Jp for emacs-devel@gnu.org; Tue, 22 Nov 2022 21:15:22 -0500 Original-Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxfI9-0008Cx-N3 for emacs-devel@gnu.org; Tue, 22 Nov 2022 21:15:22 -0500 Original-Received: by mail-pl1-x62c.google.com with SMTP id jn7so13531027plb.13 for ; Tue, 22 Nov 2022 18:15:11 -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=5H7tkR5tIXb9wy5BxW8fxS66yIPerpTcmpjtvlMFv38=; b=eOOgknpw43M6LOKDwXqSzAuegbqiOXus81aLxQ/zZTh6g1GP2uXL+EWuHjbwqRiwYB zKWNnrq2Je7aW81jrBzzvdeYx+xKbDi/pLUG68k/8ppQu2kZcber58MY2gEKuG/dMUcF AY6/98UrFOZbAy1IwiJpxcFb6CI6YdYUmk8j6Ot5YnaW9qlhkwPnBSUOQSs8xl7BpkHI wVmyPUO7EclOeDj1lDE1EzvamG/dpsOIXrOei3w4zAfbIXSiwpz3932LLZVbdq50zKkN 8lvJ6FjwQzCV+a28emvfMIzj8T6r86MrIO2zciw1U+HtH3SUBvElY8XDPAaVPAYpHn8E hqaw== 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=5H7tkR5tIXb9wy5BxW8fxS66yIPerpTcmpjtvlMFv38=; b=Wuw6a5FU4qeGWV40fxF2MSPAXZat7qFBFd9w2luewn5ZtKY41uZdcpWb3vf0a80tcg J17/S9h4ZmPiExU6T2zevZ9EKWvnmKnY7DJOxnKgDfZAWzhjP2TX9Hp/By3jOS1OVwRt 9uTmG7RrbQKaO7xe2qckIL9KU1/1RBBGyveTsWZxyIaWB1VfvGaxZFulLaQglP8VbWat qZFcU+Tqnpm0vSgt4aenuQP3Vl2JXDhwXsPEsQK4MEGpJyB0HcOgZnZSJV/ZAOJyYFBQ zN4zc6mFS295vbWo01JWN32nR4ZDC16p3SSxuKhTdzvf+htCxadSrPXeB7QazSAF1/F3 vtfA== X-Gm-Message-State: ANoB5pmAyHbZTY4XJBA0Ug1kfG4QDOROHfRD2eAJhLCUq1BfINCV9IQE nP4CBfLjBsyGltPHU/VL+ao= X-Google-Smtp-Source: AA0mqf6RRU02AGbCjmVBoDULX1ELy+1a1gFX4Goh1uy4DnStRY2mDv1vYmYfcTkZzkQLwvs3ua1g3A== X-Received: by 2002:a17:90a:ff84:b0:213:1e05:f992 with SMTP id hf4-20020a17090aff8400b002131e05f992mr7313599pjb.191.1669169710730; Tue, 22 Nov 2022 18:15:10 -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 w6-20020aa79546000000b00573a32fb554sm5301001pfq.120.2022.11.22.18.15.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2022 18:15:10 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=casouri@gmail.com; helo=mail-pl1-x62c.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:300372 Archived-At: > On Nov 22, 2022, at 6:03 PM, Yuan Fu wrote: >=20 >=20 >=20 >> 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 >=20 > Thanks for that detailed explanation :-) >=20 > 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? >=20 > IMO, the sequence would be > - parent-mode > - child-mode > - parent-hook > - child-hook > - parent-after-hook > - child-after-hook: calls fallback-mode > - fallback-parent =E2=80=A6 Perhaps it=E2=80=99s more clear with a demonstration: We define three modes, A for parent, B for child, F for fallback. Both B = and F inherits A. When we call B-mode, it automatically falls back to = F-mode in its after-hook (define-derived-mode A-mode nil "A" "A mode." :after-hook (message "A after-hook") (message "A body")) (define-derived-mode B-mode A-mode "B" "B mode." :after-hook (progn (message "B after-hook") (F-mode)) (message "B body")) (define-derived-mode F-mode A-mode "F" "F mode." :after-hook (message "F after-hook") (message "F body")) (setq A-mode-hook (list (lambda () (message "A hook")))) (setq B-mode-hook (list (lambda () (message "B hook")))) (setq F-mode-hook (list (lambda () (message "F hook")))) M-x B-mode RET produces: A body B body A hook A after-hook B after-hook (here F-mode is called) A body F body A hook A after-hook F after-hook All in all, I don=E2=80=99t see any immediate harm of falling back to = another mode like this. A=E2=80=99s body and hook run twice, but so does = it when the user manually changes B-mode to F-mode. If we want to be extra safe, perhaps we can do (run-with-idle-timer 0 = nil #'F-mode) in B-mode=E2=80=99s after-hook. Yuan=