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#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands Date: Fri, 20 Oct 2023 02:25:31 +0300 Message-ID: <78eb0b42-9603-b668-90e2-114e38e6f9ff@gutov.dev> References: <8634zyjt0k.fsf@mail.linkov.net> <8d1fb7ac-5c82-0ec2-8ae2-d09c131ec165@gutov.dev> <86edj6hyem.fsf@mail.linkov.net> <8634zitwoy.fsf@mail.linkov.net> <50d46d30-a796-b855-0d4c-690d6cb3d15b@gutov.dev> <86il88x9cy.fsf@mail.linkov.net> <4367c45c-95b3-6a29-4ba3-068a3c748452@gutov.dev> <2e34e515-a921-a969-0915-bea94c745f8b@gutov.dev> <868r9258oi.fsf@mail.linkov.net> <86edishisp.fsf@mail.linkov.net> <6fc81cbf-a21f-c5b4-aa56-e8518b8570d7@gutov.dev> <86msxgatuy.fsf@mail.linkov.net> <86y1gynr2u.fsf@mail.linkov.net> <7c72fd8c-c3f6-a974-8a4b-a081f7a9fe1a@gutov.dev> <87r0lqu7ho.fsf@catern.com> <6149d7a4-f47e-2ac4-91cf-fe144d1a4c63@gutov.dev> <6fb5f40a-48cf-c5fc-d609-df90790f66e6@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16178"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: sbaugh@catern.com, 63648@debbugs.gnu.org, Juri Linkov To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 20 01:27:03 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 1qtcPt-00040f-OF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Oct 2023 01:27:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtcPY-0008DH-FX; Thu, 19 Oct 2023 19:26:40 -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 1qtcPT-0008Cz-Oy for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 19:26:36 -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 1qtcPT-00080i-G1 for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 19:26:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtcPu-0000ZW-4i for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 19:27: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: Thu, 19 Oct 2023 23:27: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.16977579702118 (code B ref 63648); Thu, 19 Oct 2023 23:27:02 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 19 Oct 2023 23:26:10 +0000 Original-Received: from localhost ([127.0.0.1]:38176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtcP3-0000Y4-QD for submit@debbugs.gnu.org; Thu, 19 Oct 2023 19:26:10 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:41363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtcP1-0000XM-Bf for 63648@debbugs.gnu.org; Thu, 19 Oct 2023 19:26:08 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C8AD25C008D; Thu, 19 Oct 2023 19:25:34 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 19 Oct 2023 19:25:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1697757934; x=1697844334; bh=jaNQSRGq0q53atKBjQu69E0Yi0flbQOeCZX ZOBr+N2k=; b=I2t1SKfliR+4aOsAk8vD9Ic5JlVJVKgWjlX6rCnBrkPEZnE37pV LyfQEzVSKakRWrs3yWDSA6sWncdqvaURwOl6Zi1nW1VdHvD/6C8suWK0gEI8i673 xfuXW08qfOlgGxOwUYdgAXNd9HbKsEaKCdX22IJ5HwJgz6vAAH86Eax8psyuRDpq OmpC40L8tABcNjPbFAWAiLrbnB6jL7dT3ldiEt6fyWcbeToB1a7Z3dtzERP+TJ/j Z9am2NeC69AwikzDeFc6woxAwW0MCsQh8b27yfMvHCMskLsSPg2OH4FNo9QXpS7B IVBMvXhzcECvYKESKfqfA1ZTygXL2Qf0oww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1697757934; x=1697844334; bh=jaNQSRGq0q53atKBjQu69E0Yi0flbQOeCZX ZOBr+N2k=; b=AUN978oDNPumUazeXjql7+Rmtnm6kV3an7Ea98JQIr54RRGP0St +pAYPGHv379Yr/1ON6ursaX7QbcUDV5mcYQd85MWa5DeUCG3Y4gdKNdzmWihOSig URpI9SPyLaC+yIl0kLg5Jya0mnXKl+m0mJG0lJW7lWDUB6U61MPFhFLn5O6LzGiW UM/aI8hfwe0Zpr50fckjdH+nmJvqQ/kK/EWH5fhjFIH8rSPHeHI477pUI+LMqG3B XrA9rDgn1JCe2E7TixpWREOGgVQ0NMDmDXr7vzlRBsA5jo5T40k1Y4+CZPYZzq9j mNw3q2JoFe92dqbC4D5t2aZ2UfN3YFFVaBA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjeejgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedvvdej leenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Oct 2023 19:25:33 -0400 (EDT) Content-Language: en-US In-Reply-To: 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:272765 Archived-At: On 19/10/2023 22:30, Spencer Baugh wrote: >>>> I'm totally on board with adding such command, except I'm not sure if >>>> we will give away the 'C-x p p' binding to it. But as far as calling >>>> the "next" command, both project-vc-dir and project-dired currently >>>> satisfy your condition, right? >>> Yes. Although project-vc-dir and project-dired don't provide a nice >>> solution for how to implement the C-x p p single key bindings. With the >>> project-status buffer, if it had the single-key bindings, then we would >>> just say "C-x p p resolves keybindings as they would be resolved in >>> project-status". >> >> Hmm... if the goal is to just have 'C-x p p' resolve the short key >> bindings, then (setq project-switch-use-entire-map t) gets you all the >> way there, doesn't it? > > To be clear, this was just a comment about how project-status would help > us on the implementation side of single-key bindings. I still >> So the question is, do you need to be able to use non-project commands >> (like in the title of this report), and how often? >> >> If it's not very often (which would reflect my experience), then >> pressing 'o' once in a while should be a small price to pay. > > I personally use non-project commands quite frequently through C-x p p D > > Some things I run sometimes: > - find-file (if I just want to find a file from the root rather than > with project-find-file) > - vc-pull > - vc-root-diff > - various internal commands to access code review or check the build > status I guess 'find-file' could also be a command that could use the buffer text under point. Apparently, not in your usage, but in someone else's. >> BTW, when project-switch-use-entire-map is non-nil, we should probably >> display something informative to the user (e.g. some abbreviated list >> of all the bindings in project-prefix-map?), so that the users don't >> mistake the the meaning of the option, and see at least some of the >> keys they can press at that point, instead of the incorrect command >> menu. > > True. > > Automatically generating this would be kind of like which-key. I pushed a version of this to master, but one that looks more like read-multiple-choice. Reimplementing which-key would be too much, and unfortunately I don't see a way to integrate it when available either. >> Speaking of 'list-projects', though, I wonder what we could display >> for a project by default, aside from its root dir (abbreviated) and >> the number of open buffers. > > Some possibilities: > - The project type (or the vc type if it's a vc project?) > - Maybe some vc information; whether the working tree is dirty? > - The current number of warnings/errors in the *compilation* buffer for > that project if any; I implemented that for bug#63896 and it's > pretty easy These first two sound like they call for addition of more generic functions that describe a project. Though it seems like they'd be hard to explain in terms of other project backends. Maybe we could instead say "VCS responsible for project root" and "VCS short status". Anyway, both good ideas. Regarding warnings/compilations, like I said in the other bug, it does sound nice when the integration works, but the info will be empty for a lot of users. >>>>> Although, maybe we can get the best of both worlds by having C-x p p >>>>> just temporarily switch buffer? It can do (with-current-buffer >>>>> (project-status) ...) plus resolving keybindings as if they were typed >>>>> in the project-status buffer. That seems pretty elegant to me and >>>>> resolves a lot of complexities without giving up anything. >>>> >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63829 was a problem >>>> caused by a similar approach in the implementation. OTOH, >>> I was thinking we'd solve both this specific problem and the general >>> case by just saving the current buffer in a project-old-buffer variable >>> so that project-aware commands could go back and grab stuff from it. >> >> I suppose they could, but then we support using them all (?) already >> with project-switch-use-entire-map. When one has custom commands, the >> user would probably add them to project-prefix-map too. > > Er, I'm not sure I understand. Let me clarify: The "specific problem > and the general case" that I was referring to is the problem with some > implementations of project-switch-project where the buffer changes when > we use project-switch-project, meaning we can't grab stuff from the > current buffer. And we could solve that by just saving the buffer in a > project-specific variable. Which only project-aware commands would be able to take advantage of. >> The latter probably means that we cannot make just any global key >> sequence work in the *Project List* buffer (or e.g. have 'M-x gnus' >> start in a different directory depending on which line point current >> is on). But we might have a binding for a prefix command which would >> make sure the next one is run within the project room as its >> default-directory. Binding 'project-any-command' (or a variation of >> it) to 'o' seems natural in there too. Do you disagree? > > Hm, I think changing default-directory in project-list based on point is > very discoverable. Let me explain why: When you hit "g" in the > project-list buffer, I expect that it would operate on the project at > point. That seems obvious and unobjectionable. So users will be used > to being able to operate on different projects based on the value of > point. And it is (in my experience) a straightforward extension from > that to running arbitrary commands on different projects based on the > value of point. 'g' is probably fine. 'f' and the rest of such keys too. Though 'n' and, more importantly, 'p' will likely have different expectations. What if the user presses 'C-x o' while this buffer is current (and point is on one of the projects)? Or 'C-x C-s'? Would we dispatch every key sequence through our custom prefix command while this buffer is current? I can't think of an particularly damaging example right now, but the concept feels moderately dangerous. Buuut... simply changing default-directory buffer-locally in post-command hook based on what is under point might be fine.