bug#61925: 30.0.50; normal-mode does not set up local variables in temporary buffers (scratch, with-temp-buffer)

[Stefan Kangas <stefankangas@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

It seems like we're not going to be making any changes here, as this is
the expected behavior.

I'm therefore closing this bug report.