RE: [External] : Re: SQ: why transient instead of enhanced keymaps?

[Drew Adams]

First, I'm not saying anything against Transient
or proposing any alternative to it.  I get the
impression that you think this is some kind of
either-or, and you're bible-selling Transient
in that Cold War.

I merely suggested some things to maybe consider,
in a discussion of possible improvements, whether
for "enhanced keymaps" or "transient" (Subject
line) or other ways to extend user interaction.

> You are starting from the Emacs paradigm of a seemingly opaque UI that
> implements some methods for discovery (describe-*).

No.  I'm not.  Definitely not.  I myself have
provided features along the lines you describe
generally.

In particular, my key completion precedes
which-key and the like by years.  Likewise,
being able to combine multiple search patterns
and filter incrementally, etc.  All of which
aids discoverability and doesn't at all follow
any "opaque UI that implements" `describe'-like
or other predefined "discover" commands.

> Transient is the
> other way around: it puts the "what" (functionality) at the center and
> the "how" (key shortcuts) as an implementation detail. 

Only if someone categories things into "what"
functional groups.  Transient by itself doesn't
do that (IIUC).

> 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.

Blah.  You're really preaching, needlessly.

> 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.)

More needless cult-preaching.

> 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.

More of the same.

> 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

That's a rigid understanding of users and UIs.
There's no such "erroneous" or correct/perfect
predefined disposition.  Users should be able
to rearrange, filter, add/remove etc. the UI
elements they interact with, including on the
fly.

> and the
> user has a deeper understanding of the functionality exposed by the
> transient.

A user typically knows what's best for them
at any time.  Certainly no "original disposition"
can know what's always best for this or that
user, or the same user here & there, then & now.
User choice while interacting doesn't indicate
that a UI is "erroneous" or that the user's
preferred interaction is "erroneous".  And yes,
choices can be on the fly, not just made ahead
of time as user preferences.

> 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.

I won't waste more time on this.  You don't
need to sell Transient - not to me, anyway,
and I'm guessing not to others.  I thought
this thread was trying to look at things more
generally, not just trying to decide to "buy
into" this or that approach/camp.