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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: arstoffel@gmail.com,  70136@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.