This is important (and TIL OSC 3008, how do we all keep up?!), but I want something adjacent to this... perhaps people can point me in a direction.
This OSC 7501 pushes state from Program to Terminal; with an explicit running/idle/fubar "state" field but also K/V data. Then Terminal can provide interactions thereof, such as display it.
What I want is for the Program to push the terminal some map of "key:command" which is available for the terminal to provide interactions thereof. Maybe that can come through just as a key in this?
Here's the motivation: when using a TUI on a phone or tablet, the keyboarding experience is horrible (unless you have a physical keyboard). It takes up too much real estate and most of the time there's only three keys action you want to hit.
An obvious solution is to put up HTML buttons and other chrome for users to tap. Personally, I've handled that bespoke at the library+application level, where the Golang and HTML+JS container work together. There's some reusability because it can just take a BubbleTea Help Model (holds keybindings), but it is limited.
In the last few weeks, I've started seeing Claude do this unasked for me (creating parallel Web/TUI interfaces), but it was actually building more complicated Web scaffolding, rather than it being deterministically rendered from a specification by the harness.
This OSC 7501 pushes state from Program to Terminal; with an explicit running/idle/fubar "state" field but also K/V data. Then Terminal can provide interactions thereof, such as display it.
What I want is for the Program to push the terminal some map of "key:command" which is available for the terminal to provide interactions thereof. Maybe that can come through just as a key in this?
Here's the motivation: when using a TUI on a phone or tablet, the keyboarding experience is horrible (unless you have a physical keyboard). It takes up too much real estate and most of the time there's only three keys action you want to hit.
An obvious solution is to put up HTML buttons and other chrome for users to tap. Personally, I've handled that bespoke at the library+application level, where the Golang and HTML+JS container work together. There's some reusability because it can just take a BubbleTea Help Model (holds keybindings), but it is limited.
In the last few weeks, I've started seeing Claude do this unasked for me (creating parallel Web/TUI interfaces), but it was actually building more complicated Web scaffolding, rather than it being deterministically rendered from a specification by the harness.