Re: Calling another major mode in a major mode body

[Yuan Fu <casouri@gmail.com>]

> On Nov 22, 2022, at 6:03 PM, Yuan Fu <casouri@gmail.com> wrote:
> 
> 
> 
>> On Nov 21, 2022, at 4:44 PM, Phil Sainty <psainty@orcon.net.nz> wrote:
>> 
>> 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
> 
> Thanks for that detailed explanation :-)
> 
> It seems the current mode’s 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 …

Perhaps it’s 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’t see any immediate harm of falling back to another mode like this. A’s 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’s after-hook.

Yuan