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: Sat, 21 Oct 2023 12:09:19 -0400 Message-ID: References: <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> <78eb0b42-9603-b668-90e2-114e38e6f9ff@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="26497"; 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 Sat Oct 21 18:10:01 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 1quEY5-0006az-BV for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Oct 2023 18:10:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quEXg-0001Or-BM; Sat, 21 Oct 2023 12:09:36 -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 1quEXe-0001OI-WF for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 12:09: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 1quEXe-0003FP-OC for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 12:09:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1quEY6-00034j-4w for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 12:10: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: Sat, 21 Oct 2023 16:10: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.169790459511805 (code B ref 63648); Sat, 21 Oct 2023 16:10:02 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 21 Oct 2023 16:09:55 +0000 Original-Received: from localhost ([127.0.0.1]:44936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quEXz-00034L-0J for submit@debbugs.gnu.org; Sat, 21 Oct 2023 12:09:55 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:37499) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quEXw-000347-Uv for 63648@debbugs.gnu.org; Sat, 21 Oct 2023 12:09:53 -0400 In-Reply-To: <78eb0b42-9603-b668-90e2-114e38e6f9ff@gutov.dev> (Dmitry Gutov's message of "Fri, 20 Oct 2023 02:25:31 +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:272920 Archived-At: Dmitry Gutov writes: > 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 > > I don't remember how I was going to finish it :) Anyway, the point is moot now, since I'm persuaded that "C-x p p resolves keybindings as they would be resolved in project-status" doesn't work because of the buffer change. >>> 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. which-key is in GNU ELPA. So possibly it could be brought into core, if we're finding that we need it. Does that seem plausible? I could bring it up on emacs-devel, since I think which-key would be an excellent addition to core for other reasons 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? >> 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. Yes, I was thinking we'd have 'n' and 'p' do next/previous-line. 'n' is unused and 'p' is probably not necessary: you can just do C-s instead, or possibly (if we set it up) use imenu, M-g i. Possibly we should avoid using C-x p n, to reserve 'n' for this. (Or maybe C-x p n could be something that is also not necessary in the project-list buffer... maybe C-x p n could run project-list? Maybe it could be called project-navigate?) > 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. Oh, certainly not! That does sound quite dangerous and complicated and I have no idea how it would work. > Buuut... simply changing default-directory buffer-locally in > post-command hook based on what is under point might be fine. Yes, that's what I had in mind. This is much simpler than other-project-prefix.