GNU bug report logs - #70136
30.0.50; comint-mode doesn't call hack-dir-local-variables-non-file-buffer

Previous Next

Full log

Message #32 received at 70136 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 70136 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Mon, 15 Apr 2024 21:27:35 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 70136 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Mon, 15 Apr 2024 19:10:05 +0200
> 
> On Sun, 14 Apr 2024 at 13:21, Eli Zaretskii wrote:
> 
> >> From: Augusto Stoffel <arstoffel <at> gmail.com>
> >> Cc: 70136 <at> debbugs.gnu.org,  Stefan Monnier <monnier <at> 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?

You are entitled to your opinions, but this is clearly a change in
behavior that will affect a lot of users (since compilation-mode and
its descendants are very popular and widely used).  Therefore, I don't
understand why you need concrete examples: the issue is crystal clear
just by thinking about it.

> 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 contrary, .dir-locals.el affects every file in a directory, so
it is quite a blunt weapon.

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

No, I would not.

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

I'm asking mainly about the need to use make-symbol.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.