[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : Re: SQ: why transient instead of enhanced keymaps?
From: |
Drew Adams |
Subject: |
RE: [External] : Re: SQ: why transient instead of enhanced keymaps? |
Date: |
Tue, 21 Jan 2025 00:28:31 +0000 |
> > Transient is now an included battery that provides quick-access menus,
> > mostly famously for magit. People love it. But the overall effect of
> > including it is that we have two keymap systems, one of which,
> > transient, isn't customizable the same way keymaps usually are. Why
> > wasn't transient functionality provided by making keymaps better? I
> > don't see why in principle they couldn't do the same things.
>
> I have spent some time thinking about this and writing complex Transient
> menus, and would like to point out what I believe are the two marquee
> features provided by Transient but not by keymaps (at least out of the
> box):
>
> 1. Visual menus with _bespoke_ layouts.
>
> 2. "Infix" behavior, where pressing certain keys in the keymap modify
> some intermediate state. This state is then "consumed" by commands
> bound to other keys.
>
> I'm aware that this is a surface level accounting of the many
> differences, and Transient can do several other nifty things. But if
> keymaps or a keymap-adjacent library could provide these two features
> out of the box, that would cover most simple uses of Transient in the
> wild, and such menus would be much simpler to introspect and debug than
> Transient.
>
> Org mode is currently searching for a suitable menu system that provides
> these features, with Transient being one of the alternatives being
> considered:
>
> https://urldefense.com/v3/__https://yhetil.org/orgmode/87msgzh1dh.fsf@loca
> lhost/__;!!ACWV5N9M2RV99hQ!OfYl0ee5g-
> wCJuyigiOB_5rJrs4FiKft03h6J4Z7jlhdQbhYs7PNSjUWejRUnMScRPeuzjWTtGSYp1Qu7Wc3
> 9Z8Chog$
>
> Being able to use regular Emacs keymaps instead would be very useful.
>
> ------------------
>
> An explanation of the differences 1 and 2 follows:
>
> Visual menus: With something like which-key or prefix-help-command, it
> is possible to display the keymap in a user-friendly way, but there is
> no way to specify the layout -- keymap entries are essentially splatted
> into a grid (or row/column) onto the screen. Transient menus show
> keymaps on a grid too, but this grid is fully customizable. So you can
> group together related functionality in the keymap and separate these
> groups.
>
> In practice Transient menus end up with a "shape" and visual language:
> "modifier" commands towards the top, "final" commands near the bottom.
> Advanced functionality can be hidden by default and displayed on demand.
> Commands can be shown only when they are relevant to Emacs' current
> state, making the menu less busy. This purposeful design can draw the
> eye to the right places.
>
> Infix behavior: ...
All very good info; thank you.
I can think of one thing missing, wrt this point:
> you can group together related functionality
> in the keymap and separate these groups.
A customizable display, as you describe, is
definitely a plus over no ability to group
or otherwise customize the layout.
But it's also helpful for users to be able
to interactively change the layout, e.g.,
the grouping and/or the order in which the
groups are presented (and order of choices
within groups).
While not allowing the general customization
you describe, code I use:
1. Lets a coder choose the ways to group things,
using (and providing) different sort orders.
2. Lets users interactively choose among those,
i.e., switch groupings and their order on
the fly.
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
It's easy for a coder to define different sort
orders and, given the general ability to switch
among them (cycling among orders or choosing
one using completion), it's easy for users to
switch orders.
This has long been available in Icicles, and
since 2020 it's available in keysee.el and
sortie.el.
Maybe consider combining the ability to define
different groupings with an ability for users
to switch among them? This doesn't, by itself,
speak to general layout control, but it does
speak to which kinds of groups, in which order
(and to which order within groups).
- SQ: why transient instead of enhanced keymaps?, Daniel Colascione, 2025/01/12
- Re: SQ: why transient instead of enhanced keymaps?, Eli Zaretskii, 2025/01/13
- Re: SQ: why transient instead of enhanced keymaps?, Karthik Chikmagalur, 2025/01/20
- RE: [External] : Re: SQ: why transient instead of enhanced keymaps?,
Drew Adams <=
- Re: [External] : Re: SQ: why transient instead of enhanced keymaps?, Óscar Fuentes, 2025/01/21
- RE: [External] : Re: SQ: why transient instead of enhanced keymaps?, Drew Adams, 2025/01/21
- Re: SQ: why transient instead of enhanced keymaps?, Óscar Fuentes, 2025/01/21
- RE: [External] : Re: SQ: why transient instead of enhanced keymaps?, Drew Adams, 2025/01/21
- RE: [External] : Re: SQ: why transient instead of enhanced keymaps?, Karthik Chikmagalur, 2025/01/21
- Re: SQ: why transient instead of enhanced keymaps?, Karthik Chikmagalur, 2025/01/21
Re: SQ: why transient instead of enhanced keymaps?, Howard Melman, 2025/01/21