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, 21 Sep 2023 04:16:32 +0300 Message-ID: <6fc81cbf-a21f-c5b4-aa56-e8518b8570d7@gutov.dev> References: <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> <86edishisp.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="10625"; 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 Thu Sep 21 03:17:18 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 1qj8Jg-0002Xn-MT for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Sep 2023 03:17:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qj8JN-0005za-Tf; Wed, 20 Sep 2023 21:16:58 -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 1qj8JJ-0005zF-Ht for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 21:16: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 1qj8JI-0006hN-Md for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 21:16:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qj8JR-0004nT-Sk for bug-gnu-emacs@gnu.org; Wed, 20 Sep 2023 21:17:01 -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, 21 Sep 2023 01:17: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.169525901518424 (code B ref 63648); Thu, 21 Sep 2023 01:17:01 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 21 Sep 2023 01:16:55 +0000 Original-Received: from localhost ([127.0.0.1]:60684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj8JK-0004n6-Nt for submit@debbugs.gnu.org; Wed, 20 Sep 2023 21:16:55 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:39175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qj8JH-0004mo-MK for 63648@debbugs.gnu.org; Wed, 20 Sep 2023 21:16:53 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C9E7A5C0228; Wed, 20 Sep 2023 21:16:35 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 20 Sep 2023 21:16:35 -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= 1695258995; x=1695345395; bh=i8eM5GT96iDy9wnI/wsXPBZ7+mr9DudizPW DK2QRmJM=; b=i/wpe8g8J1/OKMNvwn/eSzpWFXBmhv1N7vJ0fFz2CRNUOaNny/e 9rpt6++Rfrf5TZ+RKk8+FzSsA4hP2GULvw76KC4ILHjP25Ag2G9npslsS4ThL7eF qFXboHSnqZxQT8b9l70nch1cOgzsl8uCBx5OdbsIBu4LwpsyMIw3WDkk1cHY6GcT oiNm5ZSjX1W3DjJo8O1e1mKSiRsCVqmhZvuwqaast7FVzmr+/lsg/hG17cP0/ZaG coKcn5jXpsI3wm7Lfu5iX6lrCt3ZWioDuTGvSE1sZUR9MnDEtb72ql2ikLGSNeLc AicmeqhIYoZJ2o/0n/HlkQDbSC40k2iNX/w== 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= 1695258995; x=1695345395; bh=i8eM5GT96iDy9wnI/wsXPBZ7+mr9DudizPW DK2QRmJM=; b=nsI/SBGW2GJE6/cUUV6smlMazqwW1YN1YGomeUNghoB96xz8kaj 93rhuxCwQkReIq3m8xuYsgR6INc/ikLFgqcs/SR+JFPpCQNl87Q4lW+jQkwqPdM7 gYWR2Z80dyfirndAx50jKAxtmIxWVgHFQd0Q21VPPZVW+77jt8wxBfPxx1eNKYz2 YXFNu61rSDW2tybN3mJOP/Q71vJD34vhVK33/G66O7GXJUzhrmE8Xoy4EDXZRDBY 7tOa0CAaGkBAO4RVDOUOnhygFXtRa1xBlXKBWqUjOIAvrtEyRjFMlzQsVBY+MVIZ oTRpX1RGBOVCgdplawkZ49KYsACw9I/0syw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekgedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Sep 2023 21:16:34 -0400 (EDT) Content-Language: en-US In-Reply-To: <86edishisp.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:270966 Archived-At: On 20/09/2023 20:10, 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. > > Or vice versa. Yes. >>>> 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. > > With other-project-prefix, users can run 'project-find-file' > in another project with just: > > ``` > (defun other-project-find-file () > (interactive) > (call-interactively 'other-project-prefix) > (call-interactively 'project-find-file)) > ``` Right... but they'd have to define a custom function for any such command. I think the idea behind 'other-project-prefix' is that one wouldn't have to. >>>> 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). > > No problem, project-switch-use-entire-map can be easily supported in > other-project-prefix. I'm not saying it's hard to support it there. But it could make the command less useful. >> 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. > > Agreed, a better prompt needed. Maybe with the standard C-h key for help. Some short version initially, and perhaps a more expanded if the user hits 'C-h'. >> 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. > > Maybe this short menu is not much needed. OTOH, it doesn't cause distraction. I think some menu, or an explanation, anything, is better than nothing. >>>> 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? > > Then for repeating the previously selected project it will be in the history: > 'C-x p p M-p'. Fair point. Still, that's more typing and required one to remember/know about M-p. >> 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. > > Like it does when typed e.g. 'C-x p f' in a non-project directory? Yep. >>> 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. > > And also other-project-prefix will fix such bugs as bug#65558. > >> Would it add shortcuts to the commands from the project keymap? >> Possibly. Any ideas how to inform the user about that? > > By a different prompt? Probably. Would you like to propose one? So that I have something to compare to, and have something specific to put to the vote as well.