From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: A different way to interactively pass options to commands Date: Thu, 18 Feb 2021 00:18:30 +0100 Message-ID: <8735xu9tbt.fsf@telefonica.net> References: <878s7m1mo3.fsf@gnus.org> <87ft1u9xhh.fsf@telefonica.net> <87o8giz61u.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17005"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:9i/PKjN/Ns66ruUYv8xWPpuZmmU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 18 00:19:52 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lCW6p-0004Id-BI for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Feb 2021 00:19:51 +0100 Original-Received: from localhost ([::1]:47770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCW6o-0008SX-Cg for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 18:19:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCW5g-0007xX-Fi for emacs-devel@gnu.org; Wed, 17 Feb 2021 18:18:40 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:48370) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCW5e-0006oE-Lg for emacs-devel@gnu.org; Wed, 17 Feb 2021 18:18:40 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lCW5c-00032N-Jb for emacs-devel@gnu.org; Thu, 18 Feb 2021 00:18:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265112 Archived-At: Lars Ingebrigtsen writes: > Yes, it does sound quite attractive. For instance, in Gnus, when > responding to a message, there's... I don't know how many commands. > Let's see: > > S F gnus-summary-followup-with-original > S L gnus-summary-reply-to-list-with-original > S N gnus-summary-followup-to-mail-with-original > S R gnus-summary-reply-with-original > S V gnus-summary-very-wide-reply-with-original > S W gnus-summary-wide-reply-with-original > S f gnus-summary-followup > S n gnus-summary-followup-to-mail > S r gnus-summary-reply > S v gnus-summary-very-wide-reply > S w gnus-summary-wide-reply > S B R gnus-summary-reply-broken-reply-to-with-original > S B r gnus-summary-reply-broken-reply-to > > 13! Geez. I know that pain well enough ;-) > Anyway, the interface you describe would fit this use case > well, it seems to me: The choices are whether to include the original or > not, and what subset of the To/Cc's to include in the set... Currently, > users are probably tapping `S C-h' and then learn what the binding is, > and then using that. And then forgetting until the next time. > > A Magit-like popup menu would probably be a much superior interface > here, I think? That case is a piece of cake for the Magit popup approach, it is almost too simple. What you have there is just the beginnings of a little combinatorial explosion. But then come the long-term advantages: by using the popup approach, if you wish to add a new parameter you don't need to define 13 new commands, you just register the parameter with the popup (along with its corresponding short description) and your UI problem is solved, but much better: you have discoverability, the user is not overwhelmed by a long list of commands (he just combines parameters and then starts actions), you don't have to worry about menus that grow too long, exhausting keys, etc. and the whole process is almost as fast as using the S** shortcuts you have now (one key to start the popup, one key for activating each parameter and one key for launching the action), but with an explicit interface that shows what you are about to do.