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: Thu, 19 Oct 2023 15:30:26 -0400 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9692"; 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 Thu Oct 19 21:32:02 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 1qtYkU-0002Me-7F for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Oct 2023 21:32:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtYk9-0002ID-KM; Thu, 19 Oct 2023 15:31:41 -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 1qtYk5-0002Hy-8I for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 15:31:37 -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 1qtYk3-0006Q0-Je for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 15:31:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtYkT-00022B-WA for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 15:32: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: Thu, 19 Oct 2023 19:32:01 +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.16977438637730 (code B ref 63648); Thu, 19 Oct 2023 19:32:01 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 19 Oct 2023 19:31:03 +0000 Original-Received: from localhost ([127.0.0.1]:37762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtYjW-00020a-TX for submit@debbugs.gnu.org; Thu, 19 Oct 2023 15:31:03 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:50341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtYjS-000201-9j for 63648@debbugs.gnu.org; Thu, 19 Oct 2023 15:31:01 -0400 In-Reply-To: <6fb5f40a-48cf-c5fc-d609-df90790f66e6@gutov.dev> (Dmitry Gutov's message of "Thu, 19 Oct 2023 20:17:05 +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:272757 Archived-At: Dmitry Gutov writes: > On 19/10/2023 17:00, Spencer Baugh wrote: >>>> The main downside of C-x p p D is that it necessarily switches buffers, >>>> which I often don't want. Solving that would be nice, but it would be >>>> nice to also get a shorter keybinding out of it. >>>> Actually, this gives me an idea. What if we embraced having C-x p p >>>> switch buffers? What if we had a new command which jumps you to some >>>> new "project status buffer", whose default-directory=project-root, and >>>> which has single-letter bindings for the current project-prefix >>>> commands? Similar to vc-dir. We could probably find some useful >>>> information to display in that buffer, too, like a header which extracts >>>> the status from the project's compilation buffer, or a list of the >>>> buffers in the project. >>> >>> 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 > 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. >> BTW, a more tangential idea: a list-projects command and associated >> *Project List* buffer would be nice. With: >> - a list of all remembered projects, with some details about each >> one >> - you can hit RET to open a project's project-status >> - with something (a post-command-hook?) which updates default-directory >> so that it matches the project at point, so commands you run operate >> on that project (e.g. find-file) >> - and the same single key bindings that are in project-prefix-map >> (maybe C-x p RET should be the binding to open project-status in general) >> This would be a nice complement to project-switch-project: >> list-projects >> and project-switch-project would be like list-buffers and >> switch-to-buffer. > > That reminds me of bug#63896. And I suppose some pieces could be > reused between these views. Indeed. They're two perspectives on the same data. The main reason for bug#63896 though is to get the benefits of seeing the data that project-list presents, and then be able to run a command in an arbitrary > 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 >> (The combination of list-projects and project-status buffers would >> basically be a port of what we have internally at Jane Street. While >> I'm saying that, I should mention also our equivalent of >> project-switch-project: when passed a prefix argument, all our >> equivalent-to-project-* commands will prompt for a project. This is not >> a great solution though, it doesn't scale well since every command needs >> to be aware of this prefix argument. The C-x p p design of a separate >> command which overrides the project for the next command is much better, >> and once we get a good design I plan to tell our users to start using >> C-x p p for our internal commands instead of passing the prefix >> argument.) >> >>>> If we replaced C-x p p with this command, then that would avoid all our >>>> issues with default-directory and command loops and so on, by just >>>> biting the bullet and switching buffers. >>> >>> Except when one wants to call a command that takes the current buffer >>> into account. And/or its contents in particular (e.g. file name at >>> point). >>> >>>> 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. >> It does mean that project-unaware commands can't both operate in a >> different project and on the current buffer. Is there ever a place we >> actually want that though? > > From where I'm standing, we've already passed into the "does anybody > need this" territory. But people can write their own commands, or > install packages, and apparently sometimes combine them with projects > with advanced invocations. > > I'm happy to try optimizing different workflows, but it's probably at > least equally important to make sure the new additions are consistent > and predictable (meaning, it's easy to tell in advance whether > something is going to work or not), and hopefully somewhat > discoverable too. I agree of course. > 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.