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

Tab Stop Reports #31

Open
j4james opened this issue Mar 3, 2023 · 3 comments
Open

Tab Stop Reports #31

j4james opened this issue Mar 3, 2023 · 3 comments

Comments

@j4james
Copy link
Contributor

j4james commented Mar 3, 2023

I've recently been experimenting with tab stop reports (DECTABSR), and as is usually the case, every terminal emulator seems to have a different interpretation of how they should work. So I thought this might be something else worth adding to your test collection.

I've put together a little script which runs through a few tab stop scenarios and logs the results afterwards. See https://gist.github.com/j4james/a25e6290772353c06f85c584007c2aa0

The main point of contention is whether tab stops from the 132-column range are still "visible" (i.e. they show up in a tab stop report) when you're in 80-column mode. And also whether it's possible to set tab stops in the 132-column range when you're in 80-column mode. There are also a few edge case tests, like whitespace handling in the DECRSPS sequence.

Anyway, this isn't urgent, but the next time you've got your VT340 up and running, if you feel like doing some testing, I'd be very interested to see how it handles these cases.

NB: The script starts by checking the current tab stops, assuming those are the default values, so it's important it's run soon after startup or an RIS reset. If you run the script a second time, the results won't necessarily be the same.

@j4james
Copy link
Contributor Author

j4james commented Mar 28, 2023

FYI, I was able to get someone to run the DECTABSR test on a VT525, and this is the result they got:

Photograph of a VT525 displaying the output of the DECTABSR test

I also created a test script for the other presentation report, DECCIR (cursor information report):
https://gist.github.com/j4james/570a9b7dd28dbdd8b626be2770567210

And this is what that looks like on a VT525:

Photograph of a VT525 displaying the output of the DECCIR test

Note that the latter script has a test of the color SGR sequences, since I thought that was something the VT525 might include the report, but that wasn't the case. So in theory your VT340 should produce the same output for both of these tests.

Edit: I just realised the DECTABSR script includes a test of the DECST8C sequence, which I believe is level 5, so that's the one thing that probably won't be supported on the VT340.

@hackerb9
Copy link
Owner

Thanks, James. I'm away from my VT340, but will get you that tab report as soon as I get back.

@j4james
Copy link
Contributor Author

j4james commented Jul 29, 2023

@hackerb9 Regarding your comment here:

cleanup() {
# Ugh. There appears to be no way to restore the state of GL and GR.
# (Single-shift only works for showing G2 and G3.)
# We'll just presume GL=G0 and GR=G1.
printf "${LS0}${LS1R}" # Set Graphic Left to G0, Graphic Right to G1
}

Note that the DECCIR report I mentioned above should enable you to restore the GL and GR mappings.

You can send a DECRQPSR query with the parameter value 1:

printf "\e[1\$w"

And you should get back a response looking something like this:

^[P1$u24;1;1;@;@;@;0;2;@;BB<<^[\

The 0;2 near the end indicates that GL is mapped to 0, and GR is mapped to 2.

You could also just output that response with the u changed to t, i.e. something like this:

printf "\eP1\$t24;1;1;@;@;@;0;2;@;BB<<\e\\"

That should restore all of the state, including the cursor position, page number, SGR attributes, character set designations, and a few other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants