bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-proje


From: Dmitry Gutov
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]