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: Wed, 20 Sep 2023 03:39:08 +0300 Message-ID: References: <86353axu48.fsf@mail.linkov.net> <87o7jfi00b.fsf@catern.com> <86msyhwrrg.fsf@mail.linkov.net> <86y1hs4kkg.fsf@mail.linkov.net> <86h6of66o3.fsf@mail.linkov.net> <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> 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="15082"; 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: Spencer Baugh , 63648@debbugs.gnu.org, sbaugh@catern.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 20 02:40:22 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 1qilGO-0003i7-7t for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Sep 2023 02:40:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qilG1-0002vw-0S; Tue, 19 Sep 2023 20:39:57 -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 1qilFx-0002vn-Qd for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 20:39:54 -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 1qilFx-0005VV-H3 for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 20:39:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qilG6-000077-5c for bug-gnu-emacs@gnu.org; Tue, 19 Sep 2023 20:40: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: Wed, 20 Sep 2023 00:40: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.1695170372386 (code B ref 63648); Wed, 20 Sep 2023 00:40:02 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 20 Sep 2023 00:39:32 +0000 Original-Received: from localhost ([127.0.0.1]:57941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qilFc-000068-2C for submit@debbugs.gnu.org; Tue, 19 Sep 2023 20:39:32 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57993) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qilFX-00005h-CN for 63648@debbugs.gnu.org; Tue, 19 Sep 2023 20:39:30 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 033835C0110; Tue, 19 Sep 2023 20:39:12 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 19 Sep 2023 20:39:12 -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=fm3; t= 1695170351; x=1695256751; bh=o9PgdSP/o8xbuK9H7LUbDrpN2byvbF3N9o7 W/Q81+5Q=; b=JOm4slw97GjVHRy4ThY6r8rqVy8PpACfc6NtXHedB5gZthvGMIC h3m2WyhU7e0K6T7r6XKpmP+BgPp2QR1YIa0UFW+pBASVQy9ED0EVNc6FIEETv7V8 B/vVh97q+PVGUOrrDA/3DfR2OSXDnbpNTlu6vB5Y50WUQgvPCO4CvPXpIM/mUc8b R71pX5NMaDD8594xuc9+ZejZ9Nrkj6uwPOsYsWBrGF4waDghx4jn9Jrfbj6GL15e tfxFdY4XbMe1ECNbiLSUae5SlmBvD7eFjlQcZYKi9XmgmJM8fLZA8UjOVa37cF4G hBGs2bqEHiuOhIDlZRt3HlcKUBPheciThdg== 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=fm2; t= 1695170351; x=1695256751; bh=o9PgdSP/o8xbuK9H7LUbDrpN2byvbF3N9o7 W/Q81+5Q=; b=aF2+nwBiiDnEk26yqbmkeJcpT1GbczOSBxf0m7V5McdCVuEYsgy svmVDMVin3DVxTDWd2v57ch2anatxSir0/cXXcsFJ9L1E/lKZ2FTN3d/WjIF+ZEK /XINsRKqqahESRbHU0YXbbQ04BESE3XZM3HAVRx5KJyacc4RJWFBzxzprupTcqMU 6/2LPg3vOYB2btbu2JigbqD9eI5j7DXJDP++0RImDgjRVNGI3VohRyykKyjPvZhj NTG6jTq0bEiUsDNXOsYSRtsm79KCfgjnKeOKXewCZf5KJm4dqXOEHeAzSJ1ZD7XI cilKre/8e+X8pBdprNamHvGgi0BsNMCQWqw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekvddgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Sep 2023 20:39:10 -0400 (EDT) Content-Language: en-US In-Reply-To: <868r9258oi.fsf@mail.linkov.net> 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:270898 Archived-At: On 19/09/2023 20:57, Juri Linkov wrote: >> And we should consider whether other-project-prefix should entirely subsume >> project-switch-project. Or they should remain separate commands. > > We could leave project-switch-project unobsoleted indefinitely > for users who might prefer it, and users can bind it to C-x p p. Or we keep the easier-to-use command on 'C-x p p', and the more experienced users would rebind that to 'other-project-prefix', when they learn how to use it. >> E.g. would people who customized project-switch-commands to a symbol be >> okay with not being able to use the other functionality of >> other-project-prefix? > > Symbolic project-switch-commands is supported by other-project-prefix. Yes, and that could be a problem: if I as a user want 'C-x p p' to always run 'project-find-file', for example (in the other project), but I also want to be able to sometimes call 'M-x other-project-prefix' (or use a custom binding) to run an arbitrary command in the other project. >> Or what about the variable project-switch-use-entire-map? I'm not sure >> about dropping it, at least without notifying about that in the UI somehow. > > project-switch-use-entire-map could be handled in other-project-prefix. > But is this really needed? I can't imagine why anyone might want > to disable keys from project-prefix-map. I think if project-switch-use-entire-map is still wanted, we should just keep these commands separate (the same logic as in the previous paragraph). Why not remove that option? Consider the current UI (which looks almost the same in your latest patch): user types 'C-x p p', chooses the project and then sees the prompt which only offers the options from project-switch-commands. They are not informed that any other keys could be used too. So if we were to change the default behavior, I think this UI/prompt needs to change, at the very least. Do we want to drop the whole "choose a command from the list" thing? Will that be an improvement overall, for most users? If you think so, I suppose we should make a poll somewhere. >> Finally, the current patch drops the loop, so if the user types the wrong >> key, they will need to repeat the command and choose the project again. > > Indeed, the loop now is the command loop, and maybe it's possible to > write a hack to set a catch-all in set-transient-map that is not > finished until a key in the map is typed. But as with any command, > if the user types a wrong key sequence, then need to type it again. > I do this all the time with mistakenly typed keys. I don't see why > project keys are the exception. Maybe because in the middle of it all you have interacted with Emacs to choose the other project, and that can be a significant amount of typing? I suppose, if it worked the other way (first choose the command, and then the project), it would make more sense to not care about having the user repeat the command sequence. >> So perhaps the simplest incremental change is to add other-project-prefix >> which will work with "regular" commands and keep project-switch-project for >> project commands (whether it will support "project" commands as well, can >> be optional). >> >> The downside is that it will require a different key binding (or for the >> user to redefine the current one), so I'm open to discussing all the >> questions above. > > A different key binding for the commands that do the same thing? > Only because the new command uses the command loop? project-switch-project would continue to show the menu with commands, only work with them by default, and obey project-switch-use-entire-map, which, when set to t, would enable other commands from the project keymap, but only them. All accessible via one character binding. And when project-switch-commands is set to a symbol, it would only invoke that one command without additional prompting. other-project-prefix would accept all commands but require full key sequence for the invoked command. Would it add shortcuts to the commands from the project keymap? Possibly. Any ideas how to inform the user about that?