GNU bug report logs - #66405
30.0.50; Should comint-mode call hack-dir-local-variables-non-file-buffer?

Previous Next

To reply to this bug, email your comments to 66405 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; Should comint-mode call
 hack-dir-local-variables-non-file-buffer?
Date: Sun, 08 Oct 2023 12:16:07 +0200

It currently doesn't but I think it should, since a comint is
conceptually tied to the current directory.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 66405 <at> debbugs.gnu.org
Subject: Re: bug#66405: 30.0.50;
 Should comint-mode call hack-dir-local-variables-non-file-buffer?
Date: Sun, 08 Oct 2023 13:27:37 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Sun, 08 Oct 2023 12:16:07 +0200
> 
> It currently doesn't but I think it should, since a comint is
> conceptually tied to the current directory.

Is there a compelling reason why it should (as opposed to a "why not"
kind of reason)?  Comint exists for many years, so any change in
behavior there should have a very good reason.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66405 <at> debbugs.gnu.org
Subject: Re: bug#66405: 30.0.50; Should comint-mode call
 hack-dir-local-variables-non-file-buffer?
Date: Sun, 08 Oct 2023 13:03:31 +0200

On Sun,  8 Oct 2023 at 13:27, Eli Zaretskii wrote:

>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Date: Sun, 08 Oct 2023 12:16:07 +0200
>> 
>> It currently doesn't but I think it should, since a comint is
>> conceptually tied to the current directory.
>
> Is there a compelling reason why it should (as opposed to a "why not"
> kind of reason)?  Comint exists for many years, so any change in
> behavior there should have a very good reason.

Yes.  We've been improving the editing experience in Comint with input
fontification and what not, so I think it should also have the right
project settings.  Indentation settings would be one example.  Also,
documentation lookup settings often go in the .dir-locals.el and are
relevant in a comint as well.

For me personally, it would also make
https://elpa.gnu.org/packages/buffer-env.html work more smoothly.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 66405 <at> debbugs.gnu.org
Subject: Re: bug#66405: 30.0.50; Should comint-mode call
 hack-dir-local-variables-non-file-buffer?
Date: Sun, 08 Oct 2023 14:42:34 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 66405 <at> debbugs.gnu.org
> Date: Sun, 08 Oct 2023 13:03:31 +0200
> 
> On Sun,  8 Oct 2023 at 13:27, Eli Zaretskii wrote:
> 
> >> From: Augusto Stoffel <arstoffel <at> gmail.com>
> >> Date: Sun, 08 Oct 2023 12:16:07 +0200
> >> 
> >> It currently doesn't but I think it should, since a comint is
> >> conceptually tied to the current directory.
> >
> > Is there a compelling reason why it should (as opposed to a "why not"
> > kind of reason)?  Comint exists for many years, so any change in
> > behavior there should have a very good reason.
> 
> Yes.  We've been improving the editing experience in Comint with input
> fontification and what not, so I think it should also have the right
> project settings.  Indentation settings would be one example.  Also,
> documentation lookup settings often go in the .dir-locals.el and are
> relevant in a comint as well.
> 
> For me personally, it would also make
> https://elpa.gnu.org/packages/buffer-env.html work more smoothly.

So what's our plan for when this happens to break something?

Previous Next

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