bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't call hack-dir-local-variables-non-file-buffer

[Augusto Stoffel <arstoffel@gmail.com>]

On Sun, 14 Apr 2024 at 13:21, Eli Zaretskii wrote:

>> From: Augusto Stoffel <arstoffel@gmail.com>
>> Cc: 70136@debbugs.gnu.org,  Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sun, 14 Apr 2024 11:27:28 +0200
>> 
>> Since compilation buffers go as far as to print the directory they're
>> running on at the top of the buffer, I think it's pretty clear they
>> should receive dir-local variables.
>> 
>> So I'd suggest the attached patch, which does that and also removes a
>> more limited mechanism I added some time ago to allow compilation with
>> project-specific settings.  I've CC'ed Stefan since at the time he kind
>> of supported the changes I'm now suggesting to remove.
>
> Thanks, but I think this should be optional behavior, by default off,
> because it could cause trouble in directory trees which already have
> .dir-locals.el that were not intended to affect compilation-mode (and
> its descendants, like Grep).

This seems rather hypothetical to me.  Do you have a concrete example?
The dir locals mechanism is very precise and easy to use.  Anything not
intended to affect compilation buffers should be put under prog-mode (or
a descendant), text-mode, or whatever else it's actually intended for.

On the other hand, imagine this situation: you're working on a project
with very long lines in some files, so you want your grep buffers to
look more compact.  Then you type

  M-x add-dir-local-variable RET grep-mode RET truncate-lines RET t RET

Wouldn't you be very confused that this doesn't work?

> Also, this needs a NEWS entry, I think.
>
>> +  (unless (buffer-file-name)
>> +    (let ((sym (make-symbol "hack-dir-local-variables-non-file-buffer")))
>> +      (set sym #'hack-dir-local-variables-non-file-buffer)
>> +      ;; Ensure hack-dir-locals is called only after a derived mode is set.
>> +      (push sym delayed-mode-hooks)))
>
> Why such a complicated way of using the symbol of a function that's
> defined in a preloaded Lisp file?  Am I missing some subtlety here?

This is because delayed-mode-hooks is a _list of hooks_, not a hook.
Adding (the name of) a function to it doesn't work.