From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands Date: Fri, 01 Sep 2023 11:59:41 -0400 Message-ID: References: <86jzwyxnxb.fsf@mail.linkov.net> <86o7m91z22.fsf@mail.linkov.net> <86pm6py6k4.fsf@mail.linkov.net> <86bki9y68h.fsf@mail.linkov.net> <86cz2f7bvo.fsf@mail.linkov.net> <86353axu48.fsf@mail.linkov.net> <87o7jfi00b.fsf@catern.com> <86msyhwrrg.fsf@mail.linkov.net> <86y1hs4kkg.fsf@mail.linkov.net> <86h6of66o3.fsf@mail.linkov.net> <86wmxb2qvh.fsf@mail.linkov.net> <8634zyjt0k.fsf@mail.linkov.net> <8d1fb7ac-5c82-0ec2-8ae2-d09c131ec165@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3269"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 63648@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 01 18:00:48 2023 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 1qc6Zj-0000de-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Sep 2023 18:00:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qc6Yv-0005qN-SX; Fri, 01 Sep 2023 11:59:57 -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 1qc6Yt-0005k2-1e for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2023 11:59:55 -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 1qc6Yr-0000of-QD for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2023 11:59:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qc6Z0-0006u9-VE for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2023 12:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Sep 2023 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63648 X-GNU-PR-Package: emacs Original-Received: via spool by 63648-submit@debbugs.gnu.org id=B63648.169358399926497 (code B ref 63648); Fri, 01 Sep 2023 16:00:02 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 1 Sep 2023 15:59:59 +0000 Original-Received: from localhost ([127.0.0.1]:33709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc6Yx-0006tJ-0T for submit@debbugs.gnu.org; Fri, 01 Sep 2023 11:59:59 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:50041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qc6Yv-0006t3-2Q for 63648@debbugs.gnu.org; Fri, 01 Sep 2023 11:59:58 -0400 In-Reply-To: <8d1fb7ac-5c82-0ec2-8ae2-d09c131ec165@gutov.dev> (Dmitry Gutov's message of "Fri, 1 Sep 2023 12:53:02 +0300") 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:268887 Archived-At: Dmitry Gutov writes: > On 01/09/2023 09:46, Juri Linkov wrote: >>>> (let ((default-directory "/tmp/")) >>>> (list default-directory >>>> (buffer-local-value 'default-directory (current-buffer)))) >>>> => ("/tmp/""/tmp/") >>>> Here is the shortest test case: 'C-x p p C-b' shows buffers >>>> from two projects when using let-binding for default-directory, >>>> because 'project-buffers' relies on >>>> (buffer-local-value 'default-directory buf) >>>> This could be fixed by adding special-handling of the default-directory >>>> for the current buffer in 'project-buffers'. >>> What kind of special handling? The "real" buffer-local value is hidden >>> until the "let" exists, the global value is nil, and if the buffer is not >>> a file-visiting one, there is no other file name to test against. >> Additional buffer-local variable like 'buffer-default-directory' could help. >> Or additional global variable 'global-default-directory'. Or even >> using the global value of the existing variable 'default-directory'. > > What code would use it instead of the local value of > default-directory? Only project-related code? Or other code as well? > If it's the former, we have an existing variable in the project > package. If the latter, we'd need some formal description of those > usage rules to proceed. > >>> Finally, whatever special handling we invent, would have to be mirrored by >>> all subsequent new commands (built-in and third-party) which look up the >>> value of default-directory. Especially project-related ones. How to >>> popularize that knowledge, would be the next question for whatever solution >>> we invent. >> 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. 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.) --- 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.