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

Previous Next

To reply to this bug, email your comments to 70136 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; comint-mode doesn't call
 hack-dir-local-variables-non-file-buffer
Date: Tue, 02 Apr 2024 07:54:46 +0200

This would be sometimes useful, and more consistent with other modes like
dired and diff.  Is there any reason to not do it?

Ergus: I've cc'ed you because this is potentially related to your recent
discussion in emacs-devel about "out of sources compilation"
(compilation buffers use comint-mode).

Message #8 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, spacibba <at> aol.com
Subject: Re: bug#70136: 30.0.50;
 comint-mode doesn't call hack-dir-local-variables-non-file-buffer
Date: Tue, 02 Apr 2024 14:58:45 +0300

> Cc: Ergus <spacibba <at> aol.com>
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Tue, 02 Apr 2024 07:54:46 +0200
> 
> This would be sometimes useful, and more consistent with other modes like
> dired and diff.  Is there any reason to not do it?

It doesn't sound right to me to do that by default, since comint is
used for shell-like interpreters, and those tend to change directories
at will.  Which means that dir-locals for some random directory
doesn't necessarily take such modes into consideration.

If you need that for some particular use case, can't you call it from
comint-mode-hook or something?

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70136: 30.0.50; comint-mode doesn't call
 hack-dir-local-variables-non-file-buffer
Date: Tue, 02 Apr 2024 16:03:23 +0200

On Tue,  2 Apr 2024 at 14:58, Eli Zaretskii wrote:

> It doesn't sound right to me to do that by default, since comint is
> used for shell-like interpreters, and those tend to change directories
> at will.  Which means that dir-locals for some random directory
> doesn't necessarily take such modes into consideration.

This observation makes sense, but it mostly applies to the good old
'M-x shell', not to 'M-x project-shell', other language interpreters, or
to compilation buffers.

By the way, I now realize that 'M-x compile' doesn't use comint-mode
by default.  Which raises the same question: should compilation-mode
call hack-dir-local-variables-non-file-buffer?

> If you need that for some particular use case, can't you call it from
> comint-mode-hook or something?

Sure, it's an easy customization, but the question is whether it's the
expected default behavior. :-)

Message #14 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, spacibba <at> aol.com
Subject: Re: bug#70136: 30.0.50; comint-mode doesn't call
 hack-dir-local-variables-non-file-buffer
Date: Tue, 02 Apr 2024 18:11:22 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 70136 <at> debbugs.gnu.org,  spacibba <at> aol.com
> Date: Tue, 02 Apr 2024 16:03:23 +0200
> 
> By the way, I now realize that 'M-x compile' doesn't use comint-mode
> by default.  Which raises the same question: should compilation-mode
> call hack-dir-local-variables-non-file-buffer?

Maybe.  What kind of directory-specific variables relevant to
compilation-mode would make sense?

> > If you need that for some particular use case, can't you call it from
> > comint-mode-hook or something?
> 
> Sure, it's an easy customization, but the question is whether it's the
> expected default behavior. :-)

The only way to answer that is if we see a flood of requests to have
that by default.  Without that, local customizations are perfectly
adequate.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#70136: 30.0.50; comint-mode doesn't call
 hack-dir-local-variables-non-file-buffer
Date: Sun, 14 Apr 2024 11:16:48 +0200

On Tue,  2 Apr 2024 at 18:11, Eli Zaretskii wrote:

> Maybe.  What kind of directory-specific variables relevant to
> compilation-mode would make sense?

There are some many.  To say just the first that comes to mind:
compilation-error-regexp-alist.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, Stefan Monnier <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: Sun, 14 Apr 2024 11:27:28 +0200

[Message part 1 (text/plain, inline)]

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.

[0001-Add-dir-local-variables-to-compilation-buffers.patch (text/x-patch, attachment)]

Message #23 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, spacibba <at> aol.com
Subject: Re: bug#70136: 30.0.50; comint-mode doesn't call
 hack-dir-local-variables-non-file-buffer
Date: Sun, 14 Apr 2024 13:08:55 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 70136 <at> debbugs.gnu.org,  spacibba <at> aol.com
> Date: Sun, 14 Apr 2024 11:16:48 +0200
> 
> On Tue,  2 Apr 2024 at 18:11, Eli Zaretskii wrote:
> 
> > Maybe.  What kind of directory-specific variables relevant to
> > compilation-mode would make sense?
> 
> There are some many.  To say just the first that comes to mind:
> compilation-error-regexp-alist.

I must say this is not very convincing.

What bothers me is that .dir-locals.el in a directory is not meant for
compilation-mode and similar modes, so settings there that are not
specific to modes could get in the way in *compilation* and "grep*
buffers.  But if this is optional behavior, by default off, I don't
think I'd mind.

Message #26 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: Sun, 14 Apr 2024 13:21:47 +0300

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

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?

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 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?
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.

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.

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

From: Juri Linkov <juri <at> linkov.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Tue, 16 Apr 2024 09:33:51 +0300

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

I agree this would be confusing.

IMHO, the problem is more wide and it's that dir-local variables
are not supported in non-file buffers by default.  Maybe a new
option could enable them not only in compilation buffers,
but in all non-file buffers?  Or such a new option could be
a list of non-file modes that should support dir-local variables.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com, 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: Tue, 16 Apr 2024 15:37:11 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  70136 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Tue, 16 Apr 2024 09:33:51 +0300
> 
> > 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?
> 
> I agree this would be confusing.
> 
> IMHO, the problem is more wide and it's that dir-local variables
> are not supported in non-file buffers by default.  Maybe a new
> option could enable them not only in compilation buffers,
> but in all non-file buffers?  Or such a new option could be
> a list of non-file modes that should support dir-local variables.

I'm okay with such opt-in behavior.  We can later make it the default
if enough people like it and not many complain about it.

Thanks.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, Augusto Stoffel <arstoffel <at> gmail.com>
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Tue, 16 Apr 2024 17:49:08 -0400

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

FWIW, back in 2010 (commit 8117868f0ce6) when we added support for
dir-locals to non-file buffers, we did it without even a config var to
turn it off.

AFAICT the `dir-locals.el` format should already be sufficiently
flexible to make it easy for users annoyed by the new behavior to
recover the old behavior (without affecting older Emacsen).

I think we should make an effort to enable dir-locals in as many buffers
as makes sense (but that can't be all buffers, because many buffers
aren't really related to any particular place in the file system, in
which case using the dir-locals setting of the directory that happens to
be current when the buffer was created is too arbitrary).


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 05:34:31 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Augusto Stoffel <arstoffel <at> gmail.com>,  70136 <at> debbugs.gnu.org
> Date: Tue, 16 Apr 2024 17:49:08 -0400
> 
> > 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.
> 
> FWIW, back in 2010 (commit 8117868f0ce6) when we added support for
> dir-locals to non-file buffers, we did it without even a config var to
> turn it off.

That's not the same.  Also, we did quite a few things wrong regarding
backward compatibility over the years, and I don't want us to repeat
past mistakes.

> AFAICT the `dir-locals.el` format should already be sufficiently
> flexible to make it easy for users annoyed by the new behavior to
> recover the old behavior (without affecting older Emacsen).
> 
> I think we should make an effort to enable dir-locals in as many buffers
> as makes sense (but that can't be all buffers, because many buffers
> aren't really related to any particular place in the file system, in
> which case using the dir-locals setting of the directory that happens to
> be current when the buffer was created is too arbitrary).

Like I said: I'm okay with this change provided that it is opt-in.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Tue, 16 Apr 2024 22:58:10 -0400

>> FWIW, back in 2010 (commit 8117868f0ce6) when we added support for
>> dir-locals to non-file buffers, we did it without even a config var to
>> turn it off.
> That's not the same.  Also, we did quite a few things wrong regarding
> backward compatibility over the years, and I don't want us to repeat
> past mistakes.

I can relate to that, but I can't remember bug reports (nor questions
from confused users in other channels) when we made that change, so
I don't see why we should consider that specific past choice to be
a "past mistake".
Also, I'm not seeing why "That's not the same".

> Like I said: I'm okay with this change provided that it is opt-in.

The problem with that is discovery.  Should we add a message like
"ignoring dir-locals.  See obey-dir-local-variables-in-all-non-file-buffers"?

And of course a related question is what kind of granularity to use for
the "opt-in"?  Will we add a new var every time we notice another (set
of) buffers for which we should apply dir-local vars, or would it be OK
to have a single variable?

If it's OK to have a single var: why should this var not
apply to diff-mode, log-edit-mode, ...?
Or should this var contain a list of modes which allow it, so we can
make it default to (diff-mode log-edit-mode ...)?  And maybe also allow
a t value?

And since this var is needed only to avoid breaking backward
compatibility, it would be desirable to have a plan to get rid of it in
the longer term.


        Stefan

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Wed, 17 Apr 2024 10:16:03 +0200

On Tue, 16 Apr 2024 at 09:33, Juri Linkov wrote:

> IMHO, the problem is more wide and it's that dir-local variables
> are not supported in non-file buffers by default.  Maybe a new
> option could enable them not only in compilation buffers,
> but in all non-file buffers?

One would have to exclude temporary and internal work buffers, for
efficiency reasons.

And then there's also the case of buffers that don't really "belong" to
a directory, such as *Help*.  Do you think there's a reliable way to
distinguish those from the rest?

(By the way, *Help* and friends get stuck forever in whatever
default-directory they were first created; so for instance if you do
C-x C-f in a *Help* buffer, you will see a random directory as
starting point...)

>  Or such a new option could be a list of non-file modes that should
> support dir-local variables.

I'm not a big fan of this idea.  The .dir-locals.el file is already a
list of modes, you can decide there which modes you want to be affected.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70136 <at> debbugs.gnu.org
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 10:31:42 +0200

On Tue, 16 Apr 2024 at 22:58, Stefan Monnier wrote:

> And since this var is needed only to avoid breaking backward
> compatibility, it would be desirable to have a plan to get rid of it in
> the longer term.

I definitely agree with this.  Eli's worry is about retaining
compatibility with buggy code (in this case, a hypothetical
.dir-locals.el that doesn't properly map variables to the desired
modes), so the compatibility workarounds, if any at all, should be
transitional.

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

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

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: arstoffel <at> gmail.com,  70136 <at> debbugs.gnu.org
> Date: Tue, 16 Apr 2024 22:58:10 -0400
> 
> >> FWIW, back in 2010 (commit 8117868f0ce6) when we added support for
> >> dir-locals to non-file buffers, we did it without even a config var to
> >> turn it off.
> > That's not the same.  Also, we did quite a few things wrong regarding
> > backward compatibility over the years, and I don't want us to repeat
> > past mistakes.
> 
> I can relate to that, but I can't remember bug reports (nor questions
> from confused users in other channels) when we made that change, so
> I don't see why we should consider that specific past choice to be
> a "past mistake".

I didn't mean to say that introduction of dir-locals specifically was
a mistake, I meant that in general, to make the point that not
everything we did before can be taken as a good recipe for imitation.

> Also, I'm not seeing why "That's not the same".

Because introducing a new feature is qualitatively different: it can
have no backward-compatibility problems, since no one can possibly
have existing customizations for it.

> > Like I said: I'm okay with this change provided that it is opt-in.
> 
> The problem with that is discovery.

It always is, with opt-in features.  But that doesn't mean we should
turn each new feature on, just to make it more discoverable.  There
are other considerations, and some are more important than
discoverability.

> Should we add a message like
> "ignoring dir-locals.  See obey-dir-local-variables-in-all-non-file-buffers"?

The time for April 1 jokes has come and passed this year, no? ;-)

> And of course a related question is what kind of granularity to use for
> the "opt-in"?  Will we add a new var every time we notice another (set
> of) buffers for which we should apply dir-local vars, or would it be OK
> to have a single variable?

There's no such dilemma in this case, because this feature was
proposed to be controlled by users to begin with.  So the variable was
already proposed, the discussion is just about its default value.

> And since this var is needed only to avoid breaking backward
> compatibility, it would be desirable to have a plan to get rid of it in
> the longer term.

I believe I suggested such a plan in my previous messages.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 08:59:50 -0400

>> Also, I'm not seeing why "That's not the same".
>
> Because introducing a new feature is qualitatively different: it can
> have no backward-compatibility problems, since no one can possibly
> have existing customizations for it.

That commit I referred to had AFAICT the same effect as the one
discussed here: it made some modes (diff-mode, log-edit-mode, and a few
more) obey dir-locals whereas they didn't before.
And dir-locals existed since several years before that.

Why would it be more likely for them to have .dir-locals which
accidentally affect grep-mode than diff-mode/log-edit-mode/...?

AFAICT it risked the exact same backward compatibility problems.

>> Should we add a message like
>> "ignoring dir-locals.  See obey-dir-local-variables-in-all-non-file-buffers"?
> The time for April 1 jokes has come and passed this year, no? ;-)

I'm quite serious.  From where I stand, I think most users would
want to enable this feature in they have a situation where it affects
the behavior of Emacs.


        Stefan

Message #62 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, juri <at> linkov.net
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 16:00:48 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  70136 <at> debbugs.gnu.org,
>   monnier <at> iro.umontreal.ca
> Date: Wed, 17 Apr 2024 10:16:03 +0200
> 
> On Tue, 16 Apr 2024 at 09:33, Juri Linkov wrote:
> 
> >  Or such a new option could be a list of non-file modes that should
> > support dir-local variables.
> 
> I'm not a big fan of this idea.  The .dir-locals.el file is already a
> list of modes, you can decide there which modes you want to be affected.

The difference is that if we say this should be in .dir-locals.el, we
place the burden on the users, whereas if we do what Juri suggested,
we solve this ourselves at least for modes that come with Emacs.

Message #65 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: Wed, 17 Apr 2024 16:03:18 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  70136 <at> debbugs.gnu.org
> Date: Wed, 17 Apr 2024 10:31:42 +0200
> 
> On Tue, 16 Apr 2024 at 22:58, Stefan Monnier wrote:
> 
> > And since this var is needed only to avoid breaking backward
> > compatibility, it would be desirable to have a plan to get rid of it in
> > the longer term.
> 
> I definitely agree with this.  Eli's worry is about retaining
> compatibility with buggy code (in this case, a hypothetical
> .dir-locals.el that doesn't properly map variables to the desired
> modes), so the compatibility workarounds, if any at all, should be
> transitional.

This is not so much about buggy .dir-locals.el, this is about
non-buggy .dir-locals.el that have customizations for nil mode --
those customizations might not expect non-file modes to be affected.

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

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

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: arstoffel <at> gmail.com,  70136 <at> debbugs.gnu.org
> Date: Wed, 17 Apr 2024 08:59:50 -0400
> 
> >> Also, I'm not seeing why "That's not the same".
> >
> > Because introducing a new feature is qualitatively different: it can
> > have no backward-compatibility problems, since no one can possibly
> > have existing customizations for it.
> 
> That commit I referred to had AFAICT the same effect as the one
> discussed here: it made some modes (diff-mode, log-edit-mode, and a few
> more) obey dir-locals whereas they didn't before.
> And dir-locals existed since several years before that.
> 
> Why would it be more likely for them to have .dir-locals which
> accidentally affect grep-mode than diff-mode/log-edit-mode/...?
> 
> AFAICT it risked the exact same backward compatibility problems.

So we should risk it again?

> >> Should we add a message like
> >> "ignoring dir-locals.  See obey-dir-local-variables-in-all-non-file-buffers"?
> > The time for April 1 jokes has come and passed this year, no? ;-)
> 
> I'm quite serious.  From where I stand, I think most users would
> want to enable this feature in they have a situation where it affects
> the behavior of Emacs.

If you are right, we will be able to make this on by default in Emacs
31 (assuming we introduce the opt-in feature in Emacs 30, that is: no
one has yet shown the code, so we are discussing a highly theoretical
feature).

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 13:55:55 -0400

>> That commit I referred to had AFAICT the same effect as the one
>> discussed here: it made some modes (diff-mode, log-edit-mode, and a few
>> more) obey dir-locals whereas they didn't before.
>> And dir-locals existed since several years before that.
>> 
>> Why would it be more likely for them to have .dir-locals which
>> accidentally affect grep-mode than diff-mode/log-edit-mode/...?
>> 
>> AFAICT it risked the exact same backward compatibility problems.
>
> So we should risk it again?

Well, that risk paid off because by all accounts it seems that noone
suffered (and some people benefited), so that argues in favor of taking
that risk again.


        Stefan

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

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

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: arstoffel <at> gmail.com,  70136 <at> debbugs.gnu.org
> Date: Wed, 17 Apr 2024 13:55:55 -0400
> 
> >> That commit I referred to had AFAICT the same effect as the one
> >> discussed here: it made some modes (diff-mode, log-edit-mode, and a few
> >> more) obey dir-locals whereas they didn't before.
> >> And dir-locals existed since several years before that.
> >> 
> >> Why would it be more likely for them to have .dir-locals which
> >> accidentally affect grep-mode than diff-mode/log-edit-mode/...?
> >> 
> >> AFAICT it risked the exact same backward compatibility problems.
> >
> > So we should risk it again?
> 
> Well, that risk paid off because by all accounts it seems that noone
> suffered (and some people benefited), so that argues in favor of taking
> that risk again.

That's not the kind of risk management and mitigation that I'm used
to.  It's like saying "crossing that junction on red light went well
and paid off, so let's risk that again on this next junction".

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Wed, 17 Apr 2024 14:24:51 -0400

> That's not the kind of risk management and mitigation that I'm used
> to.  It's like saying "crossing that junction on red light went well
> and paid off, so let's risk that again on this next junction".

🙂
Except that I'd seriously doubt anyone would get seriously injured if
a dir-locals setting misfires.


        Stefan


PS: admittedly, I do cross on red lights on a regular basis (not when
    driving, tho).

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

From: Juri Linkov <juri <at> linkov.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70136 <at> debbugs.gnu.org,
 Stefan Monnier <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: Thu, 02 May 2024 09:17:22 +0300

> @@ -2372,6 +2363,11 @@ compilation-mode
>    ;; some other input event happens.
>    (setq-local jit-lock-defer-time nil)
>    (setq buffer-read-only t)
> +  (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)))
>    (run-mode-hooks 'compilation-mode-hook))

Thanks for the patch.  I confirm it completely fixes the bug
reported at the end of bug#68570.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70136 <at> debbugs.gnu.org,
 Stefan Monnier <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: Fri, 20 Dec 2024 05:09:24 +0200

On 02/05/2024 09:17, Juri Linkov wrote:
>> @@ -2372,6 +2363,11 @@ compilation-mode
>>     ;; some other input event happens.
>>     (setq-local jit-lock-defer-time nil)
>>     (setq buffer-read-only t)
>> +  (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)))
>>     (run-mode-hooks 'compilation-mode-hook))
> Thanks for the patch.  I confirm it completely fixes the bug
> reported at the end of bug#68570.

I'd like to express my support for the change as well (got here from 
bug#74631).

When we added it to some modes in Emacs 24, the announcement had what 
seems like advice to call this functions in more others (see the 
corresponding NEWS).

The current opt-out options seem sufficient IMHO (the Compilation mode, 
they would also include setting enable-dir-local-variables to nil 
locally in the mode hook).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com, monnier <at> iro.umontreal.ca,
 juri <at> linkov.net
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Fri, 20 Dec 2024 09:29:08 +0200

> Date: Fri, 20 Dec 2024 05:09:24 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70136 <at> debbugs.gnu.org,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 02/05/2024 09:17, Juri Linkov wrote:
> >> @@ -2372,6 +2363,11 @@ compilation-mode
> >>     ;; some other input event happens.
> >>     (setq-local jit-lock-defer-time nil)
> >>     (setq buffer-read-only t)
> >> +  (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)))
> >>     (run-mode-hooks 'compilation-mode-hook))
> > Thanks for the patch.  I confirm it completely fixes the bug
> > reported at the end of bug#68570.
> 
> I'd like to express my support for the change as well (got here from 
> bug#74631).

I agreed with the change, provided it's opt-in.  That was 7 months
ago.

> When we added it to some modes in Emacs 24, the announcement had what 
> seems like advice to call this functions in more others (see the 
> corresponding NEWS).
> 
> The current opt-out options seem sufficient IMHO (the Compilation mode, 
> they would also include setting enable-dir-local-variables to nil 
> locally in the mode hook).

Sorry, I don't understand what you are saying here.  ("Emacs 24"?  I
thought we were discussing this for Emacs 30, for which it is now too
late, and Emacs 31?)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Augusto Stoffel <arstoffel <at> gmail.com>,
 70136 <at> debbugs.gnu.org
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Fri, 20 Dec 2024 10:54:57 -0500

>> @@ -2372,6 +2363,11 @@ compilation-mode
>>    ;; some other input event happens.
>>    (setq-local jit-lock-defer-time nil)
>>    (setq buffer-read-only t)
>> +  (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)))
>>    (run-mode-hooks 'compilation-mode-hook))
>
> Thanks for the patch.  I confirm it completely fixes the bug
> reported at the end of bug#68570.

Clearly, I'm in favor, tho I find the specific code above rather ugly.
Could we improve it?
Maybe setting a `enable-dir-local-variables-non-file-buffer` variable,
which is then obeyed in the hack-local-* functions?


        Stefan

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70136 <at> debbugs.gnu.org, arstoffel <at> gmail.com, monnier <at> iro.umontreal.ca,
 juri <at> linkov.net
Subject: Re: bug#70136: 30.0.50; compilation-mode [was: comint-mode] doesn't
 call hack-dir-local-variables-non-file-buffer
Date: Sat, 21 Dec 2024 03:32:21 +0200

On 20/12/2024 09:29, Eli Zaretskii wrote:
>> When we added it to some modes in Emacs 24, the announcement had what
>> seems like advice to call this functions in more others (see the
>> corresponding NEWS).
>>
>> The current opt-out options seem sufficient IMHO (the Compilation mode,
>> they would also include setting enable-dir-local-variables to nil
>> locally in the mode hook).
> Sorry, I don't understand what you are saying here.  ("Emacs 24"?  I
> thought we were discussing this for Emacs 30, for which it is now too
> late, and Emacs 31?)

I mean this in NEWS.24 (the last sentence in particular):

  *** Directory local variables can apply to some file-less buffers.
  Affected modes include dired, vc-dir, and log-edit.  For example,
  adding "(diff-mode . ((mode . whitespace)))" to .dir-locals.el will
  turn on 'whitespace-mode' for *vc-diff* buffers.  Modes should call
  'hack-dir-local-variables-non-file-buffer' to support this.

Previous Next

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