AI Policy Ack
Ack
What new feature do you want?
Riffing off #341 (comment), I think we should add a new var subcommand that allows you to set arbitrary variables to other strings, like variables in a shell. These variables can be used in templates in various places and when variables change the templates automatically update, pushing state changes as needed.
UI
The main UI for this new feature will be a new var subcommand, which itself will have three subcommands: set, get, and list. The subcommands will do basically exactly what you expect.
Architecture
Variables are stored in a big table daemon side. When they are modified with a shpool var set command, that change gets pushed out to all attached shpool attach procs in a new chunk frame we'll have to introduce. The attach process is then responsible for re-computing any templates which make use of these vars. At first, templates will just be supported in session names (though I think adding a new "startup command" flag that gets run right when a new shell session is created would also be a great place for these templates).
Template format
Templates will mostly follow something like shell replacement syntax, except stricter. We'll only support #{hash_curly} injection. At first I wanted to use $, but I realized that that will be annoying because shells already support that and it will be a pain to think about which layer of templating you are on. Much easier if they just use different syntax.
References to blank variables will count as the empty string.
Session templates
The only param to be templatized at first will be session names? What happens if a session name changes? The attach proc hangs up and reattaches to the new name.
Why tho?
This will allow users to do main-#{workspace} plus edit-#{workspace} and then switch both terminals at the same time by simply doing shpool var set workspace foo.
AI Policy Ack
Ack
What new feature do you want?
Riffing off #341 (comment), I think we should add a new
varsubcommand that allows you to set arbitrary variables to other strings, like variables in a shell. These variables can be used in templates in various places and when variables change the templates automatically update, pushing state changes as needed.UI
The main UI for this new feature will be a new
varsubcommand, which itself will have three subcommands:set,get, andlist. The subcommands will do basically exactly what you expect.Architecture
Variables are stored in a big table daemon side. When they are modified with a
shpool var setcommand, that change gets pushed out to all attachedshpool attachprocs in a new chunk frame we'll have to introduce. The attach process is then responsible for re-computing any templates which make use of these vars. At first, templates will just be supported in session names (though I think adding a new "startup command" flag that gets run right when a new shell session is created would also be a great place for these templates).Template format
Templates will mostly follow something like shell replacement syntax, except stricter. We'll only support
#{hash_curly}injection. At first I wanted to use $, but I realized that that will be annoying because shells already support that and it will be a pain to think about which layer of templating you are on. Much easier if they just use different syntax.References to blank variables will count as the empty string.
Session templates
The only param to be templatized at first will be session names? What happens if a session name changes? The attach proc hangs up and reattaches to the new name.
Why tho?
This will allow users to do
main-#{workspace}plusedit-#{workspace}and then switch both terminals at the same time by simply doingshpool var set workspace foo.