TUI for shpool

[GeoffChurch]

I flip between shpool sessions often, and have found it useful to have a basic TUI running that I drop back into upon detaching, so that I can select another session and attach quickly, with visual aids. It's a modal/vim-like UX that works well for me.

Examples include GeoffChurch/shpool-table (Rust), tdupes/shpiel (Bash), and GeoffChurch/shperl (Perl port of shpool-table).

shpool doesn't need to know about the TUI, so it can be completely separate, but if enough people have made their own, or would be interested, maybe it's worth including, e.g. as shpool tui.

[ethanpailes]

I think this would be a reasonable feature, though is is pretty big so it would probably take me a minute to review. Obviously if we were going to just adopt one of those implementations the one in rust would work the best. I think having it operate as a seperate process the way it does now is probably best, though we could probably also do it such that it is one process that switches back and forth between showing the tui and essentially just being a shpool attach process.

[GeoffChurch]

Would making it one process that switches back and forth preclude workflows that would run separate TUI instances in several terminals at once, like an ad-hoc tmux? And just so you're aware, shpool-table and shperl are 100% AI-generated, so it might be easier to write from scratch than to review. Thank you for shpool - it's a wonderful tool!

[ethanpailes]

I don't think making it a single process would be an issue for the the multi-terminal usecase because when the process switched back to TUI mode it would just fully hang up and from the daemon's perspective be as if it was a shpool attach process that just completely went away.

[ethanpailes]

Given that I can't really see advantages of the single-process approach, I think we should just keep the multi-proc architecture, though we could have the shpool tui process use the shpool protocol to directly query the shpool daemon rather than having it have to shell out to shpool list and whatnot. If you want to start sending PRs I would have happy to take them, though if the whole shpool-table codebase is vibe-coded I would probably prefer a human or hybrid rewrite just because that tends to produce more maintainable code IMO and maintance is one of my main priorities here.

[ethanpailes]

Your comment about the multi-terminal usecase made me wonder about a potential feature. At first I was thinking this would be part of the TUI, but thinking about it more I'm not sure it even needs a TUI involved, so this is somewhat off-topic.

Basically the idea is that it would be nice to have some way to switch multiple sessions at once. My normal workflow has one terminal for an editor, one as my "terminal terminal" and one for an agent cli. It would be nice to be able to retarget all these windows at once with a single action. There are probably some different ways you could approach this, but I'm thinking one approach would be to set a "role" plus a "meta session" when you launch your shpool attach process. Each role would have both a name and a template. A name is just a short string like the session name and a template is some pure function from your role and meta session to a session string, probably encoded as some string template (we can fill in the details later, but something like basic shell substituion is probably about right). We can configure the templates either in the config file or at the cli when you launch the shpool attach process. When you issue a switch statement, you switch the meta session (in my case a workspace name), and all these attach procs detach, then re-generate a session by re-running their role template parameterized by the new meta session and re-attach to all the new session names generated.

[GeoffChurch]

Subsets are a good idea. You could have the current view state be a map from "property types" to their current values. Each session could specify values for a subset of properties, so you might not specify any properties for generic sessions that wouldn't change (htop, "terminal terminal"), but a project-specific session could set project=personal-website. This would subsume the need for a separate meta session ("pool"?) concept.

[ethanpailes]

I think you still need some sort of explict session group mechanism because you need some way to change a parameter for all the sessions in a given group at once. Being able to add property tags isn't enough on its own unless there is a way to update all project= tags to point to the same new value at once, but that feels a bit off to me.

[GeoffChurch]

I think I'm thinking of something different/opposite then? I meant that the current view would be a specific selection of some value for each property (a total function), e.g. {project=rpi-pico, env=embedded} (project-specific sessions and sessions for debugging microcontrollers). And each session would specify a partial function, also from properties to values, so some sessions would be immune to some changes in the current view function. If you change the view from project=rpi-pico to project=website, all the sessions that specified project=rpi-pico detach and you find and attach sessions with the same session names that have project=website. So properties are what you called roles. And you wouldn't change a session's properties, just the current view's.

[ethanpailes]

Oh I see, yeah that makes sense. Translating to a more terminal app feel, I think we would just call those properties variables, and then session names become templates that support ${EXPANSION}, and every time you set a variable it re-computes all session names from the templates, reattaching any that have changed.

We could implement it by just having the attach proc store its template, then creating a special control frame in the output stream (which is already a framed protocol so no extra overhead) that tells attach procs to re-compute their session name and includes the whole updated variable list. Any attach proc that has a change bounces and re-attaches. There's already a lot of logic in place for that to support attach retries.

I think that approach would be much more backwards compatible with the existing shpool framework. Introducing extra session selectors like "meta session" and "session group" didn't really sit well with me. I like your idea a lot better.

[GeoffChurch]

Oh nice - yeah I guess template expansion automatically handles mapping/partiality, and it makes each session name be the ground truth rather than having separate partial functions. And a good TUI could probably eliminate a lot of error-prone template tedium.