Expose session terminal titles in shpool list --json and notify of changes w/ the events socket

[GeoffChurch]

It would be helpful for external tools to know the terminal title for a session and be notified when the title is changed. Coding assistant harnesses like Claude Code use the terminal title as a status indicator, so all their statuses could be seen at a glance without needing to have every session attached in different windows/tabs.

vt100 updates the title in Screen::osc2 (additionally checking that it decodes with from_utf8) and exposes it at Screen::title. vterm updates the title in State::set_title (with no decode check) but Term doesn't expose it.

The proposal is that vterm could get a getter, title changes could be checked right after updating the terminal in ‎SessionInner::spawn_shell_to_client‎ (and any events could be fired), and the title could be stored in shell.rs's Session and exposed to shpool list --json (and maybe shpool list if titles were sanitized to exclude/escape things like newlines).

Is this something worth adding to shpool?

[ethanpailes]

Yeah, that sounds like a good feature.

I think someone also requested a feature where shpool sets the terminal title based on the sesson name, which also strikes me as worth doing (though we haven't done it yet). I'm not quite sure how those two features ought to interact. Probably shpool can set the title to "shpool: " on attach and then any program in the terminal is free to clobber it? That runs into issues where we would not fully restore the state on a reattach if we are always setting the title on attach though. Maybe a better approach would be to just have shpool set the title (by injecting a set title command into the input stream) on the initial attach. That way there would be no reattach state skew.

[ethanpailes]

Oh yeah that's a good idea. I think we could do automatic title rewriting once shpool-vterm is ready. We could have it so that whenever we get a new title, check if it has the prefix shpool(<session-name): and if it doesn't we inject that prefix. It would get a bit tricky to rewrite the pty output stream, but it should be possible. We'll probably need to make a new vterm API that accepts the input bytes but then also returns some possibly re-written bytes. Handling commands split over different input chunks could be a little tricky. It will take some design work. Unfortunately, I don't think vte exposes the raw bytes that it triggers handlers off of, which could make this a bit tricky.

[GeoffChurch]

Yeah that makes sense - the idempotence is necessary and sufficient anyway bc we'd already be checking for an actual change before firing an event.

If you'd like, I can draft a PR for the original proposal (or whatever variant you think would be good) since it has standalone utility, and the title-rewriting work could be done later on

[ethanpailes]

Yeah that sounds good. I think you'll need to start with a PR to add the title access functionality to shpool-vterm and then once we've got that released we can update shpool to start taking advantage of it.

[GeoffChurch]

shpool-vterm getter PR: shell-pool/shpool-vterm#11

[GeoffChurch]

shpool list --json PR: #441