From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <86wmowgo98.fsf@gnu.org> References: <87zfuc48d5.fsf@gmail.com> <86msqc9dsa.fsf@gnu.org> <874jcjeuac.fsf@gmail.com> <86edbnajfp.fsf@gnu.org> <87mspwcn0f.fsf_-_@gmail.com> <86v84kmeh0.fsf@gnu.org> <874jc2y2ky.fsf@gmail.com> <86sezmjxbc.fsf@gnu.org> <86a5lsiuo8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7904"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70136@debbugs.gnu.org, arstoffel@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 17 14:37:18 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rx4XO-0001my-2y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Apr 2024 14:37:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rx4XD-0003u2-Hd; Wed, 17 Apr 2024 08:37:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rx4X0-0003pU-QY for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2024 08:36:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rx4Wx-0003Ww-CE for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2024 08:36:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rx4X9-00041e-PW for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2024 08:37:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Apr 2024 12:37:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70136 X-GNU-PR-Package: emacs Original-Received: via spool by 70136-submit@debbugs.gnu.org id=B70136.171335738915269 (code B ref 70136); Wed, 17 Apr 2024 12:37:03 +0000 Original-Received: (at 70136) by debbugs.gnu.org; 17 Apr 2024 12:36:29 +0000 Original-Received: from localhost ([127.0.0.1]:45999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rx4Wa-0003yB-9R for submit@debbugs.gnu.org; Wed, 17 Apr 2024 08:36:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rx4WX-0003x7-W0 for 70136@debbugs.gnu.org; Wed, 17 Apr 2024 08:36:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rx4WE-0003Sl-W3; Wed, 17 Apr 2024 08:36:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Zjs5njwcU44SQWweDMxhN0ermBy4PfLo4jEqrrsTIyA=; b=TaPVVJw55fSn NTZZ39Tk8vngC6DwdtWrPkX5WDvLIBS/G4G2YWHadXr36Er26B2pVZdHwlGRPBAOX5k9n3n4frkOf uxKMrjO9udZFou9QfPv9EQIXmePg04olxaeBUvldXio4kwWNAiTvxSJ62MMAqLdlEvDW8OIIbzsY+ zcPCUL2+Xh9XKioH3AsEm8Pt57SqWuonltTQYxosdM6queEghGcKEP+Sav8+LLdlrAO+G1W96ZP5V TznE2jhfYD1Ks0a+5Ph4jeKVEd/ust6BFD6b80KHF0UpJAwRDU/O/RJBD4NO5dlpfM+pMNpZS0YSG 6k6S+hwaKL8yKrc4UteT2w==; In-Reply-To: (message from Stefan Monnier on Tue, 16 Apr 2024 22:58:10 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283485 Archived-At: > From: Stefan Monnier > 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.