Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?)

[Psionic K <psionik@positron.solutions>]

> Do you have an example of using buffer-local variables to store
> transient state?  Directing me to an appropriate section of the
> showcase should be plenty.

It's less magic than it sounds.  I basically bypassed the infix system
when making transients for Master of Ceremonies.
https://github.com/positron-solutions/moc

`moc-dispatch` is a kind of utility dashboard for screen casting.
Besides controls, it displays various states you might not see in the
minibuffer or elsewhere.  I used dynamic :description functions rather
than infixes to display these states.  It is much simpler to bring
Elisp states into the interface this way.  There's no need and there
can be no meaning of persisting the current state of Emacs.

> like the KEEP-PRED behavior of `set-transient-map'

There's more.  Calling (or declining to call) `setup-prefix' manually
in an interactive form or using the stack manipulation commands can
switch between menus and pure interactive flows.  It's possible to
construct flows that are more program-driven than simple KEEP-PRED or
repeat maps.  Obviously we can hack them both since they are functions
that can manipulate the downstream flow.  Transient's pre-commands are
a bit complex to understand when hacking in behavior but are related
to its menu stack, something transient maps don't need to express.

Instead of talking about Transient's second system behaviors, we can
identify and fix the worst ones.  Jonas is aware of them and generally
in favor of normalizing how transient meshes with interactive, as long
as it doesn't break magit and all the other dependents.

> > org-speed-keys
> May you please elaborate?

I discovered org speed keys because I was making my own speed-key
system and came across the shadowed bindings.  The bindings are always
shadowed, even when speed keys are off.  Unlike Lispy, where I
customize the shadowing using keymaps, org speed keys has
`org-speed-commands'.  From a discoverability standpoint, it breaks
some things.  The commands are opaque.  All I see is `org-self-insert'
whereas my own bindings have unique command names on every key,
another thing I copied from Lispy.  Even if they have DWIM or
situational behavior, it is easier to identify all behavior when
starting from an entry point that doesn't implement details of other
commands.