Reusing infixes as readers in interactive forms, normalizing M-x and transient code paths

[psionic-k]

The vision is to make (interactive) forms in transient commands easier to write for both directly calling by M-x and via transient.

• If I call an interactive command by lisp, I pass arguments.
• When invoked as a command, the interactive form uses readers to obtain the values.
• When a transient suffix is called, it must extract the arguments it needs from the current prefix
• Transient infixes describe readers, but we can't easily re-use these readers to complete the interactive form
• To support both transient and M-x paths, the user must do everything explicitly using transient style code on one branch and traditional code on the M-x branch

It ends up looking like:

(transient-define-suffix pmx-frame-resolution (resolution)
  (interactive
   (if transient-current-command
       (list
        (transient-arg-value
         "resolution="
         (transient-args transient-current-command)))
     (pmx-non-infix-resolution-reader)))

Instead, I propose enabling a form like this:

(defun dual-use-suffix (arg1 arg2 arg3)
    (interactive (list (infix) (infix) (infix))
    ( ... ))

If the infix commands are made just a little smarter, they can call their reader and return the read value without using transient-infix-value. This has many advantages for reducing code size.

• Positional arguments using infix command symbols avoid transient-arg-value.
• There is no unnecessary stringly typed re-read.
• Moving the prefix versus M-x check to the infix class avoids requiring each suffix to check if transient-current-command is non-nil entirely.

To implement, when the infix is called and the transient is active, it should behave normally. When called without a prefix, the infix should be initialized, call its reader, and return its value.

Calling customized infixes without an active prefix may require smarter init-value and init-scope functions, but the user is opting into this by writing the (interactive (list (infix) (infix) (infix)) style. I will avoid discussing providing more kinds of history for infixes to usually produce smart reader defaults, but this proposal would enhance potential value in that discussion.

This usage pattern would also yield values without stringly typing values, eliminating the need to re-read them in the suffix. When providing alists for choices, we can use assoc instead of assoc-string and the even more brittle "my-value=" in calls to transient-args.

transient-args itself relies on stringly typed information to locate the arg, and IMO should be mostly relied upon for CLI interfaces.

However, CLI interfaces for new programs are not a good solution. When writing a new program, a JSON rpc style interface such as used by LSP or even an elisp extension with automatic serialization will lead to a less fragile Emacs <-> program interface. In this case, the stringly typing should be avoided and returning the infix value directly in interactive accomplishes this.

[tarsius]

There's some good suggestions here.

But please note that after the recent increase in activity here, I plan to work on Forge for the next few weeks, enjoy the holiday season, and then create releases in early January. Only after that do I intend to return to Transient. I do however plan to make Transient a primary focus at that time, and I do appreciate these suggestions.

[psionic-k]

What's Forge?

[tarsius]

../../forge

[tarsius]

Transient infixes describe readers, but we can't easily re-use these readers to complete the interactive form

You can use (transient-infix-read 'some-infix-command) for that.

[psionic-k]

The anonymous ones seem to recurse infinitely in 0.5.2. I can't try master until I update seq.

Was beginning to look at how to implement this. We have an interactive-p. What's our best way to infer transient-p?

[tarsius]

The anonymous ones seem to recurse infinitely

Yes, COMMAND has to be a symbol that identifies a infix command. I have improved the error you get when that is not the case, in 3ebb6ac.

[psionic-k]

Can you comment on the new generic transient-prefix-value function's intended role?

My understanding of this issue may have progressed. While assoc-string is rather natural in many read-functions, serializing and de-serializing non-string values with "=" as a key-value separator shouldn't be necessary. That behavior feels very CLI specific.

If I wanted to design a Transient Showcase example to completely avoid having to use read to recover lisp objects and instead use an alist for a return value of transient-args, what pieces definitely need overriding still?

My first instinct was to choose an alist because the keys of infixes are generally going to be unique and then won't require conversion to keyword symbols. In the interactive form of a suffix called independently, if it wishes to read infixes for its prefix, it would be convenient to have a function to pass in a list of infix keys, a prefix symbol, and have the reads performed and alist returned. This would eliminate need for writing the full infix symbol names correctly in every suffix's interactive form, perhaps at the expense of compiler warnings detecting that the infixes corresponding to those keys no longer exist.

The proposed form for suffixes that are dual-purpose becomes:

(transient-define-suffix dual-purpose-command (args)
  (interactive (list (transient-args 'the-prefix 'infix1 'infix2 'infix3)))
  (message "%S %S %S"
           (assq 'infix1 args)
           (assq 'infix2 args)
           (assq 'infix3 args)))

The overloading of transient-args for such purpose or with such single-minded signature is misleading at best. I make no such exact proposal and there are a number of problems with such a limited style.

To go a bit further, presume a suffix is usually called via nested prefix. It may have two "parents" to ask for values.

(transient-define-suffix dual-parent-command (foo-args bar-args)
  (interactive (list (transient-args 'foo-prefix 'infix1)
                     (transient-args 'bar-prefix 'infix2 'infix3)))
  (message "%S %S %S"
           (assq 'infix1 foo-args)
           (assq 'infix2 bar-args)
           (assq 'infix3 bar-args)))

[vspinu]

You can use (transient-infix-read 'some-infix-command) for that.

How to then call a suffix programmatically?

My use case is to read an infix, then call a suffix directly using the read infix value without going through the transient display. Essentially I want to speedup most common operations by binding to direct keys.

[tarsius]

How to then call a suffix programmatically?

Like for other commands, use call-interactively if you want the interactive form to be used.

My use case is to read an infix, then call a suffix directly using the read infix value without going through the transient display. Essentially I want to speedup most common operations by binding to direct keys.

You can define your own suffix commands to work like that (if not invoked from a prefix, read values for some arguments using transient-args).

(interactive
 (list (if (eq transient-current-command 'usual-prefix)
           (transient-args 'usual-prefix)
         (list (transient-infix-read 'one-of-the-args)))))