Adding a tabulated-list-mode interface

[vermiculus]

Checklist

• I've read the README's Issues section.
• I'm running the latest agent-shell version.
• I'm running the latest agent version (ie. Claude Code, Geminig CLI).
• I'm running the latest agent ACP package (ie. claude-code-acp).
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

Enhancement

Would you like a built-in agent-shell-list interface? I've got one I've been working on and it seems to do the job pretty well. (It's very similar to agent-shell-manager in concept, actually, but cursory testing of that one shows some performance issues – and it's not on MELPA.)

I can absolutely appreciate if you want to control scope here, though this does feel 'missing' from agent-shell. My goal with agent-shell-list is to provide 'just enough' functionality to encourage other standard emacs functionality to be used (display-buffer-alist, list-processes, etc) rather than trying to bake it all in. (This philosophy is one of the things I appreciate about agent-shell.)

BTW, great work with this. It's made working with these tools a breeze for me in ways that would not be possible outside emacs.

[xenodium]

Thanks for kicking this off Sean. While I'm excited to see agent-shell grow in usefulness, I also have to be mindful of all the code I inherit through pull requests, which I'm now becoming the maintainer of. For features that could potentially live as complementary packages, I'm encouraging folks to build separately. In those instances, I'm happy to link to those projects from agent-shell.

Having said all that, it'd be good get a better feel for the proposal before suggesting a separate package. Do you have screenshots you could share? Could you share code to look at? It's ok if it's a rough draft still, but gives me a sense of the size of the feature. Hope that makes sense.

[xenodium]

BTW, great work with this. It's made working with these tools a breeze for me in ways that would not be possible outside emacs.

Thank you! That's great to hear. If you or your employer are in a possition to do so, consider sponsoring to make this a more sustainable effort.

[vermiculus]

Thank you! That's great to hear. If you or your employer are in a possition to do so, consider sponsoring to make this a more sustainable effort.

Already looking into it; just need to talk to my wife :-)

I will get screenshots in sometime today. I have a few that I've taken for internal distribution of my patches, but they contain IP. I will need to grab fresh ones.

It's possible this could be spun off, though there are some more patches that would need to be made and maintained in core. It does however feel akin to magit-list-repositories in how I use it.

[xenodium]

All good. No hurry.

though there are some more patches that would need to be made and maintained in core.

Yup. Sounds good. This also enables other packages to integrate if need be.

[vermiculus]

Here are the bindings that have been added on top of the base tabulated-list-mode:

N  agent-shell-list-new-shell
C  agent-shell-list-interrupt
k  agent-shell-list-kill
o  agent-shell-list-goto-shell
O  agent-shell-list-goto-viewport
m  agent-shell-list-cycle-session-mode
M  agent-shell-list-set-session-mode
v  agent-shell-list-set-session-model
t  agent-shell-list-open-transcript

Total, it looks like I've written 24 functions – 11 of which are commands (mostly wrappers). Just under 300 LOC. I could probably trim that down if I remove the 'wrapper' commands (like agent-shell-list-open-transcript) and include the necessary interactive forms in the functions they wrap (eg agent-shell-open-transcript). Folks have differing opinions on which is more maintainable; I personally prefer using interactive as it tends to create a better lisp API.

[vermiculus]

Here's what I've been working with: main...vermiculus:agent-shell:sa/list-agent-shells. Note Claude was used during development but like I attested above, I stand by what I'm presenting here.

Looks like the major thing definitely needed in core would be the following:

diff --git a/agent-shell.el b/agent-shell.el
index 57b1a71..8c3d2b8 100644
--- a/agent-shell.el
+++ b/agent-shell.el
@@ -489,6 +490,7 @@ HEARTBEAT, and AUTHENTICATE-REQUEST-MAKER."
         (cons :last-entry-type nil)
         (cons :chunked-group-count 0)
         (cons :request-count 0)
+        (cons :last-activity-time nil)
         (cons :tool-calls nil)
         (cons :available-commands nil)
         (cons :available-modes nil)
@@ -777,6 +779,7 @@ Flow:
     (map-put! (agent-shell--state) :request-count
               ;; TODO: Make public in shell-maker.
               (shell-maker--current-request-id))
+    (map-put! (agent-shell--state) :last-activity-time (current-time))
     (cond ((not (map-elt (agent-shell--state) :client))
            (when-let (((map-elt shell :buffer))
                       (viewport-buffer (agent-shell-viewport--buffer
@@ -871,6 +874,7 @@ otherwise returns COMMAND unchanged."
 
 (cl-defun agent-shell--on-notification (&key state notification)
   "Handle incoming notification using SHELL, STATE, and NOTIFICATION."
+  (map-put! state :last-activity-time (current-time))
   (let-alist notification
     (cond ((equal .method "session/update")
            (let ((update (map-elt (map-elt notification 'params) 'update)))

There are number of things that would make my life easier in terms of pulling out shared logic, but this would be pretty much required without serious hacks.

Expanding the core interactive forms obviously would not be doable as a separate package, but the argument for doing so is lessened if it's a separate package, anyway.