Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extract terminal version from query responses #1798

Closed
dankamongmen opened this issue Jun 20, 2021 · 14 comments
Closed

extract terminal version from query responses #1798

dankamongmen opened this issue Jun 20, 2021 · 14 comments
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Milestone

Comments

@dankamongmen
Copy link
Owner

While I don't really look forward to heuristics based off details like terminal version, if we want to e.g. support older versions of kitty, it will be necessary to do so (for instance, I'm freely using the C=1 functionality introduced in 0.20.0). when a terminal provides its version in response to a query, we ought go ahead and make that available to our termdesc logic.

also, we ought document all the terminal queries and such that we send, and how we use the responses.

@dankamongmen dankamongmen added documentation Improvements or additions to documentation enhancement New feature or request labels Jun 20, 2021
@dankamongmen dankamongmen self-assigned this Jun 20, 2021
@dankamongmen
Copy link
Owner Author

Contour version is available following "contour " in the XTVERSION response.
XTerm version is available in parentheses following "XTerm" in the XTVERSION response.
Kitty version is available via a XTGETTCAP iirc.
WezTerm version is available following "Contour " in the XTVERSION response.

@kovidgoyal
Copy link

FYI I added XTVERSION support to kitty a while ago as well, kovidgoyal/kitty@057084a

@dnkl
Copy link
Contributor

dnkl commented Jun 20, 2021

FYI I added XTVERSION support to kitty a while ago as well, kovidgoyal/kitty@057084a

Same for foot: https://codeberg.org/dnkl/foot/commit/c3274fd97e7469c0261a7cbd0d4f4095bf96ca1f

@dankamongmen
Copy link
Owner Author

FYI I added XTVERSION support to kitty a while ago as well, kovidgoyal/kitty@057084a

oooh nice i'll likely use this, great

@dankamongmen
Copy link
Owner Author

notcurses 2.3.4 by nick black et al on XTerm 366

sweet!

@dankamongmen
Copy link
Owner Author

ok, kitty added XTVERSION 6 days ago in 0.21.2, and foot seven days ago. so i'm going to go ahead and write version acquisition as it was supported, and if someone is using a new XTVERSION-capable instance, it'll get pulled out of there instead. hrmmm, which means i need be prepared for the version to be specified more than once.

@dankamongmen
Copy link
Owner Author

kitty version was P+q6b697474792d71756572792d76657273696f6e (at least according to kitten query_terminal), egads.

foot's version was in the secondary device attributes response, the query for which i actually just removed tonight due to it "not yielding any information of value"

i think i might just hope for newest versions from y'all, and use XTVERSION across the board

@dankamongmen
Copy link
Owner Author

notcurses 2.3.4 by nick black et al on Contour 0.2.0-unreleased-master-96b8f89

@dankamongmen
Copy link
Owner Author

recent kitty gives it to us like this, which means if we can get MLTerm to support XTVERSION, we ought be able to drop our XTGETTCAP[TN] entirely:

read(0, "\33]11;rgb:0000/2222/1111\33\\\33P>|kitty(0.21.1)\33\\\33

@dankamongmen
Copy link
Owner Author

notcurses 2.3.4 by nick black et al on Kitty 0.21.1

@dankamongmen
Copy link
Owner Author

recent foot gives it to us like this

33\\\33P>|foot(1.7.2-365-g7632e16)\33\\\33[?1

@dankamongmen
Copy link
Owner Author

2021-06-21-210905_1024x600_scrot

@dankamongmen
Copy link
Owner Author

w00t alright!

@dankamongmen
Copy link
Owner Author

notcurses 2.3.4 by nick black et al on WezTerm 20210613-233622-35b26767

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants