From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#58784: 28.2; project-buffers incorrect under let-bound default-directory Date: Wed, 2 Nov 2022 01:35:58 +0200 Message-ID: <208cd0a0-8244-9cac-ff16-9ef23b56ca9b@yandex.ru> References: <0b56cc0a-b8d4-86dc-4b67-217387aeb1b2@yandex.ru> <938BB7EA-3902-4025-98B5-914D514B4A63@toadstyle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28112"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: 58784@debbugs.gnu.org To: Sean Devlin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 00:37:30 2022 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 1oq0oz-0007BN-P2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 00:37:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq0oa-0003Rm-9o; Tue, 01 Nov 2022 19:37:04 -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 1oq0oY-0003RE-Rk for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 19:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oq0oY-0004Kr-Kt for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 19:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq0oY-0007Ot-2g for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 19:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2022 23:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58784 X-GNU-PR-Package: emacs Original-Received: via spool by 58784-submit@debbugs.gnu.org id=B58784.166734577128386 (code B ref 58784); Tue, 01 Nov 2022 23:37:02 +0000 Original-Received: (at 58784) by debbugs.gnu.org; 1 Nov 2022 23:36:11 +0000 Original-Received: from localhost ([127.0.0.1]:44440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq0nj-0007Nm-5w for submit@debbugs.gnu.org; Tue, 01 Nov 2022 19:36:11 -0400 Original-Received: from mail-wm1-f47.google.com ([209.85.128.47]:40501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq0ne-0007NF-NY for 58784@debbugs.gnu.org; Tue, 01 Nov 2022 19:36:09 -0400 Original-Received: by mail-wm1-f47.google.com with SMTP id v124-20020a1cac82000000b003cf7a4ea2caso260817wme.5 for <58784@debbugs.gnu.org>; Tue, 01 Nov 2022 16:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=sxd6XPXbqjGlwm0Uq3+TuwmU7RWEszKQgcwb1zdvGBc=; b=hn8AneWRpC4Db53Ogu7yS91S68FKYtHWfxspd6eV207KLIt/Icihf+ObR5VZIi1hSh YBcaPOcPpMSXVx4aezFCLKnaN6bsNIZbKu6wGetVqpaJDQGzXL/iEk+8bjCQJmyFPQcT 2ikbGYHySrzqwvGd7j3SGzJW3rwUSpvkjmBfmawd+snsraz0cdzzLLH44siUKmjJeJXm AVo8znqVc/5/GECDJ/gk2Q98o9paOgLXqcGuEV84e6Qu4Ea7bM/Cl4uAewe6GiPoX6Kq 1Y4cPb7WL54zvBbeopu0nUpxUQSHg5YMxt7poeov/AiKgyHQiWLJAgLDgJHJqlvaLkSC 47Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sxd6XPXbqjGlwm0Uq3+TuwmU7RWEszKQgcwb1zdvGBc=; b=lymzdE00OaBTU1KSoa+fy+6/QrweYVIvfKm/bbpOz3u9pkoxsR59YX5NRJ+O0+XvSO v7W2Zxd3cvbhQR3yPMiZ2WEpg6MPIon3bZxXF9BunmyStYPG2zisolymytCcqilgPVWx H7mFfov9f4co1NfGQP64mI6w39pyq7fiQt0f9/0jO+mOc6Vj9d8Tasv8yqFkrrzxBSIK Ctx+iVcThskYNtzMA+erFguqG7631jW8jG/iPPzcSpMuLZl/fZaX5VZgBZgFZmbdhEUR fHanU84awjuIi2ki46PV24jVXl5roeN765xm1Ihxr1jv95DdBiI45GT9SnMVG577v6Oz qEaA== X-Gm-Message-State: ACrzQf2b+q0KDDP8gMeXw98N3ggko0/zFi3+VlXDPjRuIGvFPyGKyInL 3NmTKqcGyKWENbEWIjTrjfE= X-Google-Smtp-Source: AMsMyM7ABmhAeWZDsODZAyPPxF3l8R+basxNnWeYQDzgRkVuHG+ol2xWhgPNyQlJH6l24fTSQb+HYA== X-Received: by 2002:a1c:4c16:0:b0:3cf:6f1a:9038 with SMTP id z22-20020a1c4c16000000b003cf6f1a9038mr9944265wmf.151.1667345760751; Tue, 01 Nov 2022 16:36:00 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q5-20020a5d6585000000b00228cd9f6349sm11272805wru.106.2022.11.01.16.35.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 16:36:00 -0700 (PDT) Content-Language: en-US In-Reply-To: <938BB7EA-3902-4025-98B5-914D514B4A63@toadstyle.org> 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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246823 Archived-At: Hi Sean, On 31.10.2022 19:47, Sean Devlin wrote: >>> In the last form, project-buffers includes the current buffer (i.e. the >>> scratch buffer in our example) with the results. (This is true even if >>> the current buffer is visiting a file in some unrelated directory.) >>> This matters because the command project-switch-project let-binds >>> default-directory before calling project-switch-commands. This means >>> that if you set project-switch-commands to some function that calls >>> project-buffers, you will get incorrect results. >>> For example, evaluate the following forms in order: >>> (defun my-list-project-buffers () >>> "List the current project's buffers." >>> (interactive) >>> (let ((buffer-list (project-buffers (project-current t))) >>> (buffer-name (project-prefixed-buffer-name "my-project-buffer-list"))) >>> (with-current-buffer (get-buffer-create buffer-name) >>> (erase-buffer) >>> (save-excursion >>> (dolist (buffer buffer-list) >>> (insert (buffer-name buffer)) >>> (insert ?\n)))) >>> (switch-to-buffer buffer-name))) >>> (setq project-switch-commands #'my-list-project-buffers) >> >> Looks like a reimplementation of projectile-ibuffer, seems useful. > > Yeah, in my real configuration, I defined this as an ibuffer filter, but I thought a simpler example would be better for the bug report. Right, thanks. >>> ;; list tmpfile but also scratch >>> (project-switch-project "/tmp/") >> >> Not sure how to fix this, though. In bug#53626 we discussed a somewhat similar problem, and a let-binding seems impossible to "escape". >> >> What else can we do? One option is to change the signature of every compatible command to take the project object as its first argument. Might have been more realistic when the package was first written, too much breakage now, probably. >> >> Another would be to add a new var to help override the project choice without touch default-directory. >> >> Something like the attached. Please try it out. > > I agree, the fix is not obvious. > > A workaround I used in my configuration is to add an advice to project-switch-project to wrap it in a with-temp-buffer form. This way, it’s only the default-directory of the temp buffer that gets corrupted. Not a very clean solution, but it seems to work. Unfortunately, you need to remember to do this in many places; for example, I had to do the same thing in my project-ibuffer command. > > Your solution looks cleaner. I gave it a try (along with disabling my advice), and it seems to work pretty well. Thanks for the fix! Actually I like your solution better. It might be less obvious when reading, but it's shorter and fully backward compatible. So I just pushed that fix to master. > There might be some more places where it needs to be applied. For example, project-prefixed-buffer-name still inspects the default-directory. (Maybe project-prefixed-buffer-name should just call project-root or similar?) In both places where project-prefixed-buffer-name is currently invoked, default-directory is set a specific binding just before that. So I think it would have been fine even with the other fix. Or on a higher level, it acts on the current buffer, so referencing default-directory seems okay. > I think there’s still some fragility in the project-buffers function, since any callers need to be careful not to bind default-directory. It might be useful to call this out in the doc string or in the manual. I suppose it could use improvement, but I'm not sure what phrasing would stop someone from making such a mistake. After all, I knew its implementation and made it anyway. Perhaps the docstring should simply say that the buffers are matched on the basis of their default-directory value. In the default implementation, that is (custom backends could choose their own strategy). Would that help?