unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: A different way to interactively pass options to commands
Date: Wed, 17 Feb 2021 22:48:42 +0100	[thread overview]
Message-ID: <87ft1u9xhh.fsf@telefonica.net> (raw)
In-Reply-To: 878s7m1mo3.fsf@gnus.org

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.




  parent reply	other threads:[~2021-02-17 21:48 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 19:50 A different way to interactively pass options to commands Clemens
2021-02-17 20:07 ` Stefan Monnier
2021-02-17 20:20   ` Lars Ingebrigtsen
2021-02-17 22:05     ` Stefan Monnier
2021-02-19  5:41   ` Richard Stallman
2021-02-19 14:30     ` Stefan Monnier
2021-02-17 20:09 ` Lars Ingebrigtsen
2021-02-17 20:32   ` Clemens
2021-02-17 20:42     ` Lars Ingebrigtsen
2021-02-17 20:58       ` Clemens
2021-02-17 21:24       ` Clemens
2021-02-17 22:15         ` Stefan Monnier
2021-02-17 21:48   ` Óscar Fuentes [this message]
2021-02-17 22:23     ` Stefan Monnier
2021-02-17 22:47       ` Óscar Fuentes
2021-02-17 23:52         ` Clemens
2021-02-17 22:24     ` Lars Ingebrigtsen
2021-02-17 23:18       ` Óscar Fuentes
2021-02-18 10:09         ` Lars Ingebrigtsen
2021-02-18  1:16       ` Doug Davis
2021-02-18 10:03         ` Lars Ingebrigtsen
2021-02-18 10:39           ` Kévin Le Gouguec
2021-02-18 10:52             ` Lars Ingebrigtsen
2021-02-18 12:13               ` Dmitry Gutov
2021-02-18 17:45                 ` Stefan Kangas
2021-02-18 17:55                   ` Dmitry Gutov
2021-02-18 18:32                     ` Stefan Kangas
2021-02-19 11:59                       ` Lars Ingebrigtsen
2021-02-18 16:11               ` Óscar Fuentes
2021-02-18 15:40             ` Stefan Monnier
2021-02-18 16:28               ` Development snapshots on GNU ELPA (was: A different way to interactively pass options to commands) Kévin Le Gouguec
2021-02-19 12:01               ` A different way to interactively pass options to commands Lars Ingebrigtsen
2021-02-19 14:32                 ` Stefan Monnier
2021-02-21 14:55                   ` GNU-devel and NonGNU-devel (was: A different way to interactively pass options to commands) Basil L. Contovounesios
2021-02-21 20:25                     ` GNU-devel and NonGNU-devel Stefan Monnier
2021-02-25  2:19                       ` Basil L. Contovounesios
2021-02-19 15:44               ` A different way to interactively pass options to commands Jonas Bernoulli
2021-02-19 18:23                 ` Clemens
2021-02-22  0:18                   ` Jonas Bernoulli
2021-02-22  2:39                     ` T.V Raman
2021-02-22  9:17                     ` Questions about transient (was: Re: A different way to interactively pass options to commands) Joost Kremers
2021-02-22 15:08                       ` Jonas Bernoulli
2021-02-22 21:06                         ` Joost Kremers
2021-02-22 16:25                       ` [External] : " Drew Adams
2021-02-23 12:15                     ` A different way to interactively pass options to commands Stephen Leake
2021-02-23 19:06                       ` Jonas Bernoulli
2021-02-19  5:42     ` Richard Stallman
2021-02-19  6:32       ` Stefan Kangas
2021-02-21 10:28   ` Phil Sainty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ft1u9xhh.fsf@telefonica.net \
    --to=ofv@wanadoo.es \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).