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 10:00:05 -0400 Message-ID: References: <86wmxb2qvh.fsf@mail.linkov.net> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22575"; 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 16:00:45 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 1qtTZr-0005eB-Ag for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Oct 2023 16:00:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtTZl-0004ts-RF; Thu, 19 Oct 2023 10:00:37 -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 1qtTZj-0004jW-Se for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 10:00: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 1qtTZj-0006Gg-Gr for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 10:00:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtTa9-0005gB-RO for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 10:01:01 -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 14:01: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.169772404421786 (code B ref 63648); Thu, 19 Oct 2023 14:01:01 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 19 Oct 2023 14:00:44 +0000 Original-Received: from localhost ([127.0.0.1]:37348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtTZq-0005fG-87 for submit@debbugs.gnu.org; Thu, 19 Oct 2023 10:00:44 -0400 Original-Received: from mxout1.mail.janestreet.com ([38.105.200.78]:34975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtTZl-0005em-Lv for 63648@debbugs.gnu.org; Thu, 19 Oct 2023 10:00:41 -0400 In-Reply-To: <6149d7a4-f47e-2ac4-91cf-fe144d1a4c63@gutov.dev> (Dmitry Gutov's message of "Thu, 19 Oct 2023 15:49:20 +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:272739 Archived-At: Dmitry Gutov writes: > On 19/10/2023 15:22, sbaugh@catern.com wrote: >> Hm, I personally think having to hit the extra "o" is undesirable. >> I'm >> not sure whether "C-x p p o" would be an improvement over the current >> state of the world: you can already hit "C-x p p D" to run >> project-dired, so you end up in dired at the root of the project, and >> then run whatever command you like with default-directory=project-root. > > It makes this capability apparent, and it's still one fewer keystroke > (and 'o' is close to 'p', too). One fewer keystroke? Oh, since one has to hit shift to type D... there's equivalently C-x p p v, then, which is the same length in keystrokes. >> 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". 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. (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. 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? > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58784 probably doesn't > apply (most of the time; unless the projects are nested or whatever). Indeed.