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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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