Re: A different way to interactively pass options to commands

["Óscar Fuentes" <ofv@wanadoo.es>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Clemens <clemera@posteo.net> 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.