Re: SQ: why transient instead of enhanced keymaps?

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

>> > For example, when choosing key completions
>> > you can choose to sort:
>> >
>> > 1. By key name, prefix keys first
>> > 2. By key name, local keys first
>> > 3. By command name, alphabetically
>> 
>> A good Transient UI shows related functionality together. Function is
>> what matters. A key being prefix, local or whatever is an implementation
>> detail. And names are mostly accidental.
>
> I beg to differ.  I often want to use a local key.
> Just as I use `C-h m' to learn about the current mode.
>
> I often want to know what local keys there are, or
> what prefix keys there are, or explore a prefix key.
>
> And I often want to match against command names for
> commands bound to keys.  Or even match part of a
> key sequence and part of a command name - e.g.
> filter names for certain kinds of commands, learn
> their keys, and choose a command/key.
>
> Key completion isn't (in my use) only, or even
> mainly, about completing a key to use it.  It's also
> about discovery and guidance.
>
> For the same reason I like to be able to back up
> from any level in the key forest, and back down
> other branches.  Including menu branches.  That's
> another thing I might have mentioned as missing:
> go up, down, and all around - all key bindings.

You are starting from the Emacs paradigm of a seemingly opaque UI that
implements some methods for discovery (describe-*). Transient is the
other way around: it puts the "what" (functionality) at the center and
the "how" (key shortcuts) as an implementation detail. Once you know the
entry point, Transient is at least as discoverable as a menu, with the
added capability of setting an "execution environment" (parameters) for
the action that you execute.

Emacs' traditional UI has its good points, but the paradigm of prefix +
command + prompt has severe limitations once the complexity of the
system reaches certain point (Emacs reached that point eons ago.)
Prefixes are arcane, commands proliferate and prompts are inconvenient
when they are many and/or have a well defined default value (which
causes even more command proliferation.) Transient decouples options and
parameters from actions, and everything is there neatly displayed on
your face, no need for C-h or M-x describe-whatever (supposing that you
know the meaning of the terminology used, Magit's Transient will not
teach you what a squash merge is.)

Once the user passed the discovery phase, Transient does not impair
ergonomy (it is as agile and more mnemonic than a regular Emacs
keybinding.) But the great advantage of Transient is that it greatly
restrains command proliferation: instead of providing 2^N commands that
essentially do the same for combinations of N options, you get the
ability to independently set any of N options and execute one command.
I'm dramatizing a bit, but that's what it did when Magit migrated from
the old UI to the Transient-based one.

All of the above does not preclude the possibility of customizing the
shortcut keys, having Transients inside Transients, etc. I don't know if
Transient currently implements those features, but they are not against
its UI principles.

Rearranging the groups of options and commands has little value. Those
are shown in logical groups, which means that their position reveals
information to the user and makes easy to find them. So moving they
around would indicate that the original disposition is erroneous and the
user has a deeper understanding of the functionality exposed by the
transient. At that point the user may best served by creating his own
transient for that functionality. Furthermore, rearranging the transient
would often be not much simpler than implementing a new transient
(copy&paste helps on that case.)

Hiding/showing options and actions is convenient, OTOH. Again, I don't
know if Transient implements this.