"`contour generate terminfo`" should work like `contour capture` and ask the actual running client instead of sucking something hardcoded out of the executable #1289
Currently there are a lot of issues with regards to the feature set of Contour and the compatibility of Contour's ever changing terminfo file with what is available in upstream repositories. It seems most of them are caused by the fact that Contour's implementation is destructively incompatible with Xterm, which most applications otherwise expect.
See #1244, #1240, #1102, #630, #388(?), #233.
(TODO[@whisperity]: Even recently, using the terminfo available from 0.3.12 release with a 0.4.xxx client makes Vim unusable because there are no colours and things are spazzing out. I will update this with details on Thursday when I'm around my Windows machine.)
The backbone of this functionality seems to exist already due to #203!
The core problem is that in non-local sessions (either within Docker, or through SSH), the programs are grabbing whatever terminfo is available on the serverside or containerside. If there is a Contour installed which terminfo is not in synch with what the client frontend understands, things will simply not work.
Now, currently, there is a very troublesome potential workaround for this, and that is scripting around the ssh command to first generate terminfo on the clientside, scp it somehow onto the server (analogously copy it into the Docker...) and then on the server side, run some script that magically sets TERMINFO and TERMINFO_DIRS to this resulting location.
My current problem is that I have no idea how I would pull off such a script, especially on Windows.
Instead, I suggest to implement a terminfo generator logic that works akin to the capture feature. When called, the backend shim (on the remote side) should ask the client frontend (on the local side) over VT to give back exactly the terminfo that client supports.
That way, scripting of "putting the received terminfo to the right location and setting the env vars" could be restricted to be needed only on the remote end. Which is likely Linux, and easier to script.
In case dropping the current generate terminfo implementation in favour of this suggested one would break some functionality or use case, it could instead be called like contour generate terminfo from-frontend to return whatever is receipt over VT, while contour generate terminfo could keep returning whatever is baked into the executable contour resolves to at the point of execution.
Caution! Just like capture's format, this communication is an ABI-level thing, which MUST stay consistent as we evolve the project, so a lot of care should be taken here!
And perhaps this SHOULD also be added to the 0.3 line (pre-Qt6/QML) as a backport release so that older serverside (remote) machines could benefit from this functionality...
To ensure the facilitation of such a "server"-side scripting, a way to grab the version of the local Contour frontend should also be available. contour version does NOT suffice because that would return the version of the contour binary on the serverside! However, as far as I can tell, a terminfo can have multiple aliases:
❯ contour generate terminfo to -
contour|contour-latest|Contour Terminal Emulator,
Could we add the exact version (in some format) of the client that is generating this into this output?
For example, given:
❯ contour version
Contour Terminal Emulator 0.3.12.4932
the terminfo should have an alias like this (or if .s are forbidden, perhaps with -s?):
❯ contour generate terminfo to -
contour|contour-latest|contour-0.3.12.4932|Contour Terminal Emulator,
Currently there are a lot of issues with regards to the feature set of Contour and the compatibility of Contour's ever changing terminfo file with what is available in upstream repositories. It seems most of them are caused by the fact that Contour's implementation is destructively incompatible with Xterm, which most applications otherwise expect.
See #1244, #1240, #1102, #630, #388(?), #233.
(TODO[@whisperity]: Even recently, using the terminfo available from 0.3.12 release with a 0.4.xxx client makes Vim unusable because there are no colours and things are spazzing out. I will update this with details on Thursday when I'm around my Windows machine.)
The backbone of this functionality seems to exist already due to #203!
The core problem is that in non-local sessions (either within Docker, or through SSH), the programs are grabbing whatever terminfo is available on the serverside or containerside. If there is a Contour installed which terminfo is not in synch with what the client frontend understands, things will simply not work.
Now, currently, there is a very troublesome potential workaround for this, and that is scripting around the
sshcommand to firstgenerate terminfoon the clientside,scpit somehow onto the server (analogously copy it into the Docker...) and then on the server side, run some script that magically setsTERMINFOandTERMINFO_DIRSto this resulting location.My current problem is that I have no idea how I would pull off such a script, especially on Windows.
Instead, I suggest to implement a terminfo generator logic that works akin to the
capturefeature. When called, the backend shim (on the remote side) should ask the client frontend (on the local side) over VT to give back exactly the terminfo that client supports. That way, scripting of "putting the received terminfo to the right location and setting the env vars" could be restricted to be needed only on the remote end. Which is likely Linux, and easier to script.In case dropping the current
generate terminfoimplementation in favour of this suggested one would break some functionality or use case, it could instead be called likecontour generate terminfo from-frontendto return whatever is receipt over VT, whilecontour generate terminfocould keep returning whatever is baked into the executablecontourresolves to at the point of execution.Caution! Just like
capture's format, this communication is an ABI-level thing, which MUST stay consistent as we evolve the project, so a lot of care should be taken here!And perhaps this SHOULD also be added to the 0.3 line (pre-Qt6/QML) as a backport release so that older serverside (remote) machines could benefit from this functionality...
To ensure the facilitation of such a "server"-side scripting, a way to grab the version of the local Contour frontend should also be available.
contour versiondoes NOT suffice because that would return the version of thecontourbinary on the serverside! However, as far as I can tell, a terminfo can have multiple aliases:Could we add the exact version (in some format) of the client that is generating this into this output?
For example, given:
the terminfo should have an alias like this (or if
.s are forbidden, perhaps with-s?):