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: Thu, 19 Oct 2023 20:17:05 +0300 Message-ID: <6fb5f40a-48cf-c5fc-d609-df90790f66e6@gutov.dev> 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; 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="1391"; 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 Thu Oct 19 19:18:00 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 1qtWej-00007J-NP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Oct 2023 19:17:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtWeP-00015A-4h; Thu, 19 Oct 2023 13:17: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 1qtWeN-00014y-Kt for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 13:17:35 -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 1qtWeN-0002g9-At for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 13:17:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtWen-0003KX-Vp for bug-gnu-emacs@gnu.org; Thu, 19 Oct 2023 13:18: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 17:18: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.169773586912775 (code B ref 63648); Thu, 19 Oct 2023 17:18:01 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 19 Oct 2023 17:17:49 +0000 Original-Received: from localhost ([127.0.0.1]:37708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtWea-0003Jy-VY for submit@debbugs.gnu.org; Thu, 19 Oct 2023 13:17:49 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:33707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtWeU-0003Ja-M2 for 63648@debbugs.gnu.org; Thu, 19 Oct 2023 13:17:47 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5DD603200A3A; Thu, 19 Oct 2023 13:17:09 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Oct 2023 13:17:09 -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= 1697735828; x=1697822228; bh=r5+7kJdBD0Vel8a50Vfl8JsrCjEdQGRNONQ JxL3uExU=; b=Cena81z3V8aWWnpK+7otTme+sR9yQ44Lm2Na5XemjukeQu82Tkz rFoNfK8Al4TPaMapYPYc5zQKIkzPWGdTb18DYBibVMzIZq12WStxocZsEYijC1g/ LUl4JeRl9yZ67VZ6JtDXpuZV6h6GHQqiYEIMX8MgR/CrPgG3XdvA81tDNqu7B07n 9NCflPuH4d3SWL2xCBdCkf56Nr5NUAubScmmIAqmBhTMdzSWO1f0uB8In/LPejM3 W9YaWnK7+AofUQIF+a6bPCokGGbjzOSdv371bjSpkJRljfq5de7BJAK33MAMKb// O1vmJad8edHvikJLXa0RRmuIivbyoXac4dA== 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= 1697735828; x=1697822228; bh=r5+7kJdBD0Vel8a50Vfl8JsrCjEdQGRNONQ JxL3uExU=; b=dQopJ2pCVdNZQEcA+eG0JSGAF/o5KNM77IQYS8l0o4nMT+Ru1Z2 OjhgNUnk5+E+F/DF3Qfu1rmXCG7LPyFaRx4URri8GaU3sBdXvJsV5yznkICz4+mo ocyLOn/TeWNDOZDJS3SVQmMNlSO3ycCIxmzxBK7q9c7srKITd3CaRagvlO2WORA4 rmcW9DCeP/PakqYSMB/sGbdqzn3TthoxrA99wVEtC5VNSG2TX92tYba1fC3CVyEY YEuGG4Esn8dayRrBPuh9UPK52uKKFJUFuJg3FsijLx9qgwbRINam+peRMCdqt340 0WFoDI++sCUZBQ5oG+ifUOklrPX4wP3eLiQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjeeigdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Oct 2023 13:17:07 -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:272750 Archived-At: On 19/10/2023 17:00, Spencer Baugh wrote: >> 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. 'C-x p p v' is a bit farther, but close enough indeed. >>> 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? 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. 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. > 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. 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. > (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. > 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. 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?