Hello @xenodium,
I have been using the following customization in my agent-shell configuration for several months. It has become part of my normal workflow, so I would like to ask whether it would make sense upstream.
When the agent is responding, I often start typing my next request without first invoking the queue command. My customization remaps self-insert-command so that typing while the shell is busy opens the queue prompt reader, with the first typed character already inserted.
This makes queuing feel like writing a normal prompt. I can start typing as soon as I think of a follow-up instead of first invoking agent-shell-prompt-queue.
I used the same behavior while a session is still being initialized, except with the new-deferred session strategy, where typing into the initial prompt should continue to work normally. This might not be needed now in the latest versions of agent-shell I suppose
This is the code:
(defun +agent-shell-self-insert-or-queue ()
"Insert character normally, or queue a request if the shell is busy."
(interactive)
(if (or (shell-maker-busy)
(and (not (eq agent-shell-session-strategy 'new-deferred))
(not (map-nested-elt
(agent-shell--state)
'(:session :id)))))
(let ((char (string last-command-event)))
(agent-shell-prompt-queue
(agent-shell--prompt-queue-read :initial char)))
(self-insert-command 1)))
(keymap-set agent-shell-mode-map
"<remap> <self-insert-command>"
#'+agent-shell-self-insert-or-queue)
Possible upstream behavior
For automatic queueing, typing a self-inserting character while the agent is busy would open agent-shell--prompt-queue-read, initialized with that character. Typing would continue to insert normally when the shell is ready for input.
There may be an interaction with printable characters that already have direct bindings in agent-shell-mode-map, such as n, p, r, +, -, and 0. A remapping of self-insert-command alone may not cover those keys while the shell is busy.
Would this behaviour make sense as part of agent-shell-prompt-queue.el? If so, would you prefer separate issues and PRs?
Checklist
Edits
The earlier draft of this issue also discussed another possible feature which has now been moved to #791
Hello @xenodium,
I have been using the following customization in my agent-shell configuration for several months. It has become part of my normal workflow, so I would like to ask whether it would make sense upstream.
When the agent is responding, I often start typing my next request without first invoking the queue command. My customization remaps
self-insert-commandso that typing while the shell is busy opens the queue prompt reader, with the first typed character already inserted.This makes queuing feel like writing a normal prompt. I can start typing as soon as I think of a follow-up instead of first invoking
agent-shell-prompt-queue.I used the same behavior while a session is still being initialized, except with the
new-deferredsession strategy, where typing into the initial prompt should continue to work normally. This might not be needed now in the latest versions of agent-shell I supposeThis is the code:
Possible upstream behavior
For automatic queueing, typing a self-inserting character while the agent is busy would open
agent-shell--prompt-queue-read, initialized with that character. Typing would continue to insert normally when the shell is ready for input.There may be an interaction with printable characters that already have direct bindings in
agent-shell-mode-map, such asn,p,r,+,-, and0. A remapping ofself-insert-commandalone may not cover those keys while the shell is busy.Would this behaviour make sense as part of
agent-shell-prompt-queue.el? If so, would you prefer separate issues and PRs?Checklist
Edits
The earlier draft of this issue also discussed another possible feature which has now been moved to #791