GNU bug report logs - #63648
29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: sbaugh <at> catern.com, 63648 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#63648: 29.0.90; project.el: with switch-use-entire-map,
 switch-project errors on non-project commands
Date: Sat, 2 Sep 2023 04:47:44 +0300

On 01/09/2023 18:59, Spencer Baugh wrote:
>>> Hopefully there should be not much trouble such as in 'project-buffers'.
>>
>> I think there exists a class of commands (existing and potential ones)
>> that would use default-directory with exact same purpose and
>> expectations.
> 
> Thinking about it, I guess there's (roughly) two classes of commands
> which want different things from default-directory, classes 1 and 2:
> 
> 1. wants whatever the current value of default-directory is (and gets
> this by just using default-directory as a variable)
> 
> 2. wants the value of default-directory for some specific buffer X (and
> gets this either with buffer-local-value or by using
> with-current-buffer)
> 
> If we could change 1 without changing 2, then we'd be happy.

Yes, maybe.

> This gets back to my earlier suggestion, that we have some way of
> binding a variable which does not change the buffer-local value.
> Supporting that would require fairly deep changes in C of course.
> 
> (But actually, maybe it would be useful for Lisp threads?  In fact,
> maybe Lisp threads already support this?  Because when you're in a
> thread and you bind default-directory, you don't want that to affect any
> other threads, you only want it to affect code running directly under
> you.)

It might be useful, sure. But as for how reasonable would be to have 
such a primitive, I'd rather defer to our language gurus (a question on 
emacs-devel would be a good idea).

> Anyway, I'm coming around to the idea that actually the "changing the
> local value of default-directory" problem isn't that big of a deal.  We
> can do something special for project-buffers, and that would make things
> work OK with the next-default-directory approach, and if we run into
> further problems in the future, we'll rethink at that time.
>
> Maybe with more time running with the code, we will come up with
> something new and clever.

It's a minor problem, but we've already went through two rounds on 
bug#58784 (first finding one solution, then a problem with it, and 
ending up with project-current-directory-override). I'd rather not throw 
out a solution that covers the known edge cases too eagerly.

So I don't like an idea of a "special fix" in project-buffers, but if 
anyone has a specific patch to show, please go ahead.

Previous Next

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