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: Wed, 17 Feb 2021 22:48:42 +0100 Message-ID: <87ft1u9xhh.fsf@telefonica.net> References: <878s7m1mo3.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="19171"; 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:8FUF8wv0zardiprSrAxXCJYGaT0= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 22:50:11 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 1lCUi2-0004qn-34 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 22:50:10 +0100 Original-Received: from localhost ([::1]:41352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCUi1-0001Am-4Z for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 16:50:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCUgm-0000fK-Qu for emacs-devel@gnu.org; Wed, 17 Feb 2021 16:48:52 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:40900) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCUgk-00062n-RE for emacs-devel@gnu.org; Wed, 17 Feb 2021 16:48:52 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lCUgi-0003J3-BM for emacs-devel@gnu.org; Wed, 17 Feb 2021 22:48:48 +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:265091 Archived-At: Lars Ingebrigtsen writes: > Clemens writes: > >> Adjusting commands on call is traditionally done via universal prefix >> argument. This is mostly nice for numeric repetitions but often it is >> also used to change the behavior of a command in other ways and >> sometimes even multiple ways depending on the number of times `C-u` is >> used. > > Yes, `C-u' is the only hammer we have here, unfortunately... (And > adding commands that are variants of each other.) > >> The recent discussion around changing `interactive' made me think >> about ways to improve that. Magit has shown a real nice UI approach to >> pass options with its transient menus. Maybe a simpler but similar >> mechanism could be added which could also be configured via >> `interactive'. Any opinions on this? > > What does the Magit UI look like? Here is what happens when you invoke the `magit-diff' command: https://magit.vc/screenshots/popup-diff.png BTW, Org has an interface for some commands that looks like Magit's, but in essence has some fundamental differences. When Magit's popup interface was conceived (by yours truly) we were running out of shortcuts: git has too many features and its interface is so barroque, that it was not realistic to provide a command-based interface based on Emacs' command+modifier+prompt interface. Another problem to overcome was ergonomy and discoverability. The later was provided by displaying the available options along with a short description and the former by requiring a minimal and consistent sequence of keypresses. For instance: showing the log of the current repository with default options is `ll' (two els); showing the log of all branches is `la'; showing the log of all branches along with the corresponding patch for each commit is `l-pa', and so on. This works very well at wrapping the complexity of git's UI with another one that is more approachable and agile. So, could Emacs take advantage of something like this? I think so. Think of VC, just to mention a package on the same application area (furthermore, VC has to deal with multiple backends, which makes it potentially more complex than Magit.) Adding a new switch to some VC command is a big deal, from the UI perspective and from the integration with other optiones, and then you end either with a new command or with a new variable, of which existence the user is not aware until he does some investigation. I could implement an analogue, Emacs-oriented Magit popup system, or just borrow the implementation of it that Magit's current maintainer so well polished. IIRC Org considered doing that on the past. The second part is to decide to which part of Emacs to apply it. VC is a good candidate, although a bit too large since the internal code must be adapted to groak the information provided by the popup and that may require too many changes and potential destabilization, as well as being disruptive from the UI point of view. IMAO Emacs presents very good oportunities to improve its usability. The command filtering that we are currently discussing is just a tiny step (and a sizable basis) on that direction that, along with other much larger changes, I envisioned on the past.