[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61925: 30.0.50; normal-mode does not set up local variables in tempo
From: |
Eli Zaretskii |
Subject: |
bug#61925: 30.0.50; normal-mode does not set up local variables in temporary buffers (scratch, with-temp-buffer) |
Date: |
Sat, 04 Mar 2023 12:19:31 +0200 |
tags 61925 notabug
thanks
> Date: Fri, 3 Mar 2023 00:11:13 +0100
> From: Wolfgang Scherer <Wolfgang.Scherer@gmx.de>
>
> The command `normal-mode' does not set file local variables, if a
> buffer does not have a `buffer-file-name'. This affects *scratch* and
> buffers created using `with-temp-buffer'.
>
> The behavior changed at some time between Emacs version 20.5.2.2 and 20.6.3.
> See output from various Emacs versions further below.
>
> If that was an intentional change, it should be prominently documented
> to avoid the confusion when examples do not work in a *scratch* buffer.
This was an intentional change, yes.
And AFAICT, it _is_ documented in the ELisp Reference manual:
-- Command: normal-mode &optional find-file
This function establishes the proper major mode and buffer-local
variable bindings for the current buffer. It calls ‘set-auto-mode’
(see below). As of Emacs 26.1, it no longer runs
‘hack-local-variables’, this now being done in ‘run-mode-hooks’ at
the initialization of major modes (*note Mode Hooks::).
And the documentation of run-mode-hooks says:
-- Function: run-mode-hooks &rest hookvars
Major modes should run their mode hook using this function. It is
similar to ‘run-hooks’ (*note Hooks::), but it also runs
‘change-major-mode-after-body-hook’, ‘hack-local-variables’ (when
the buffer is visiting a file) (*note File Local Variables::) ^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The user manual indeed didn't mention this caveat; I've now mentioned
that aspect there (and also in the doc strings of the relevant
functions).
(The change in Emacs 26 that caused this as a side effect was to fix
bug#15577 and bug#23407.)
> I would even recommend a warning prompt in normal-mode, when called
> interactively.
I think such a warning could be an annoyance.