From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Devlin Newsgroups: gmane.emacs.bugs Subject: bug#58784: 28.2; project-buffers incorrect under let-bound default-directory Date: Wed, 2 Nov 2022 11:18:49 -0400 Message-ID: <35907670-3546-45B8-8E3C-2C482B8E3464@toadstyle.org> References: <0b56cc0a-b8d4-86dc-4b67-217387aeb1b2@yandex.ru> <938BB7EA-3902-4025-98B5-914D514B4A63@toadstyle.org> <208cd0a0-8244-9cac-ff16-9ef23b56ca9b@yandex.ru> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.51\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21544"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58784@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 16:20: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 1oqFXZ-0005Lr-0y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 16:20:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqFXB-0007UG-Un; Wed, 02 Nov 2022 11:20:06 -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 1oqFXA-0007T7-AT for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:20:04 -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 1oqFX8-00055z-HP for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:20:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqFX7-0007gS-T1 for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sean Devlin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 15:20:01 +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.166740234829469 (code B ref 58784); Wed, 02 Nov 2022 15:20:01 +0000 Original-Received: (at 58784) by debbugs.gnu.org; 2 Nov 2022 15:19:08 +0000 Original-Received: from localhost ([127.0.0.1]:46985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqFWG-0007fF-Db for submit@debbugs.gnu.org; Wed, 02 Nov 2022 11:19:08 -0400 Original-Received: from mail-qk1-f172.google.com ([209.85.222.172]:34482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqFWE-0007el-Fw for 58784@debbugs.gnu.org; Wed, 02 Nov 2022 11:19:07 -0400 Original-Received: by mail-qk1-f172.google.com with SMTP id 8so11927850qka.1 for <58784@debbugs.gnu.org>; Wed, 02 Nov 2022 08:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toadstyle-org.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0BNBbS6vEzwBHC7nM7TgexaHUCSBemxzgxwqikTSfRs=; b=Rg0gVvPYWQI/btpNuNt+S5UPSDoLJgNv8yhuw06i3gsdVh/P2DT9udU6p9yvl5915s q9PNffKhvou6r7KRs9K+yIJAGEriawPPhJhO/+/BnvTabylox7fDY+FCZnZBebwcb4sA lnXbucuyK0c1HPZhmuKwCR1wfSSMY2UEjjyDOPn1z0/HMLeX1fa4cwLcIaa+ZCGfMTI6 tegw4oY4Ylj09rgdLwnXCOSE5feYbjc5rVrtRqTKp/PNomtHp5sooKUzMgePzun+gwVa r/iAI49rc2ffR3BHw8qbfKDDODQNFgk4F1ZlXnkgJJjsmWszp5eBEuMeXlN6vK7+yB53 i/0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0BNBbS6vEzwBHC7nM7TgexaHUCSBemxzgxwqikTSfRs=; b=Rt/9pw1f0JlvkR+4dmXX0/Z2G3C/cBUGyLC94MLKW+M+gtMFGoLS697Qj+ORck5CEb 0WW9eaWCcn1Uxct7tn7DDdDNBPTcerKENxGWF7+0yQEh5GFP81+F0R/mf92yZuA7iNkP +OV0SOpxOkMFDYCD96Y0EMi92NJWpAo87/yn6uTG0DisVcDo7WGTtPYfJPhjX1jWnzpP DhDtC3bRNlnFcaLLoFKJAY0GAidkMbCUIVvd6gsLQaiwRKxbs8q8p7Q7STsqaoKdcbe/ LppVrkP9XJacJM78ZZye0pkYM1VQdtGm6zbvDa51zDDSpZFoSxkBiUF0j6pmUl663tW9 R+Ww== X-Gm-Message-State: ACrzQf17qvkpOuKaL+uSVt39megtHmG9U9NCBq4uBFta3uGxZLkSCphX j3RwoQV2143uEfM+WYLzQHlhzQ== X-Google-Smtp-Source: AMsMyM598mfbMUEowl5pBgH48coJ7FSTbUFbzIHIWAuIOFzQ5A12MPqqsOKESLlte6jkjpLvYmXdng== X-Received: by 2002:a05:620a:1a99:b0:6ee:c795:46a6 with SMTP id bl25-20020a05620a1a9900b006eec79546a6mr17774939qkb.286.1667402340863; Wed, 02 Nov 2022 08:19:00 -0700 (PDT) Original-Received: from smtpclient.apple (pool-173-56-106-162.nycmny.ftas.verizon.net. [173.56.106.162]) by smtp.gmail.com with ESMTPSA id az42-20020a05620a172a00b006bb87c4833asm8669277qkb.109.2022.11.02.08.19.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2022 08:19:00 -0700 (PDT) In-Reply-To: <208cd0a0-8244-9cac-ff16-9ef23b56ca9b@yandex.ru> X-Mailer: Apple Mail (2.3731.300.51) 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:246878 Archived-At: Hi Dmitry, > On Nov 1, 2022, at 7:35 PM, Dmitry Gutov wrote: >=20 > Hi Sean, >=20 > On 31.10.2022 19:47, Sean Devlin wrote: >=20 >>>> 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) >>>=20 >>> 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. >=20 > Right, thanks. >=20 >>>> ;; list tmpfile but also scratch >>>> (project-switch-project "/tmp/") >>>=20 >>> Not sure how to fix this, though. In bug#53626 we discussed a = somewhat similar problem, and a let-binding seems impossible to = "escape". >>>=20 >>> 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. >>>=20 >>> Another would be to add a new var to help override the project = choice without touch default-directory. >>>=20 >>> 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=E2=80=99s 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! >=20 > Actually I like your solution better. It might be less obvious when = reading, but it's shorter and fully backward compatible. >=20 > So I just pushed that fix to master. Great, thanks! >=20 >> 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?) >=20 > 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. >=20 > Or on a higher level, it acts on the current buffer, so referencing = default-directory seems okay. Sounds good. >=20 >> I think there=E2=80=99s 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. >=20 > 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. >=20 > 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? Yeah, I think a high-level description of the default strategy would be = useful. Thanks again for your help!