Add support for horizontal margin sequences #19408

New Issue

claunia · 2026-01-31T06:42:23Z

claunia commented

2026-01-31 06:42:23 +00:00

Originally created by @j4james on GitHub (Feb 19, 2023).

Description of the new feature/enhancement

The DECSLRM escape sequence lets you set left and right margins, so you can wrap your output within a given horizontal range, and also limit the scrolling within those boundaries. This is useful for apps like multiplexers, where you can have two panes side by side, and you need to be able to scroll the one side independently of the other.

Proposed technical implementation details (optional)

There are actually two sequences we need to implement for this. The first is DECLRMM (Left Right Margin Mode), without which the margin functionality won't be active. It's disabled by default because you can't use horizontal margins at the same time as double-width line attributes.

The main sequence is DECSLRM (Set Left Right Margins), which works similarly to the DECSTBM sequence (Set Top Bottom Margins) which we already support. But there a bunch of operations we then need to update to take those margins into account - cursor movement, insert and delete ops, text output, etc.

I should also note that the DECSLRM sequence clashes with the ANSISYSSC sequence which we already support. But the way most modern terminals deal with that is to disable ANSISYSSC when the DECLRMM mode is enabled. So by default CSI s is ANSISYSSC (as we have it now), but with DECLRMM enabled it's interpreted as DECSLRM.

Originally created by @j4james on GitHub (Feb 19, 2023). # Description of the new feature/enhancement The `DECSLRM` escape sequence lets you set left and right margins, so you can wrap your output within a given horizontal range, and also limit the scrolling within those boundaries. This is useful for apps like multiplexers, where you can have two panes side by side, and you need to be able to scroll the one side independently of the other. # Proposed technical implementation details (optional) There are actually two sequences we need to implement for this. The first is `DECLRMM` (Left Right Margin Mode), without which the margin functionality won't be active. It's disabled by default because you can't use horizontal margins at the same time as double-width line attributes. The main sequence is `DECSLRM` (Set Left Right Margins), which works similarly to the `DECSTBM` sequence (Set Top Bottom Margins) which we already support. But there a bunch of operations we then need to update to take those margins into account - cursor movement, insert and delete ops, text output, etc. I should also note that the `DECSLRM` sequence clashes with the `ANSISYSSC` sequence which we already support. But the way most modern terminals deal with that is to disable `ANSISYSSC` when the `DECLRMM` mode is enabled. So by default `CSI s` is `ANSISYSSC` (as we have it now), but with `DECLRMM` enabled it's interpreted as `DECSLRM`.

claunia added the Issue-Feature Help Wanted In-PR Area-VT Needs-Tag-Fix Product-Terminal labels 2026-01-31 06:42:23 +00:00

claunia closed this issue

2026-01-31 06:42:24 +00:00

claunia commented

2026-01-31 06:42:25 +00:00

@j4james commented on GitHub (Feb 19, 2023):

This is another one of those sequences which has lots of edge cases that aren't always clearly specified, and which everyone handles differently. So before I submit a PR for this, it would be ideal if we could get some of those aspects clarified by testing on a real DEC terminal.

To that end I've created a Python script with a series of test cases here:
https://gist.github.com/j4james/2eae626e461175cfcc29a304e066ae87

@KalleOlaviNiemitalo and @jerch, I'd be very grateful if either of you would be willing to give that a run on your VT420 or VT525. It's setup as an automated test, so you shouldn't need to do anything other than run it, and the results will be logged in a file named margins.log.

Note that it could take a while, because it uses DECRQCRA queries to read the screen content when checking the output. But it outputs the results of each test as they're executed, so you should be able to tell whether it's frozen for some reason.

I should also mention that it highlights the results with reverse video if they've "failed", but that's just based on my best guess of how things should work. I wouldn't be surprised if the real terminals behave differently from my expectations.

Also note that some of the operations were only supported on the VT510 and above, so you can definitely expect to see failures for those if testing on a VT420. I think that includes HPA, HPR, VPA, VPR, CNL, CPL, CHT, and CBT.

So @KalleOlaviNiemitalo, if the test is running really slowly, and you want to save some time, feel free to comment those ones out. You'll find all the test groups listed at the bottom of the script, so for example, you can comment out the test_hpa() call to skip that particular group.

@j4james commented on GitHub (Feb 19, 2023): This is another one of those sequences which has lots of edge cases that aren't always clearly specified, and which everyone handles differently. So before I submit a PR for this, it would be ideal if we could get some of those aspects clarified by testing on a real DEC terminal. To that end I've created a Python script with a series of test cases here: https://gist.github.com/j4james/2eae626e461175cfcc29a304e066ae87 @KalleOlaviNiemitalo and @jerch, I'd be very grateful if either of you would be willing to give that a run on your VT420 or VT525. It's setup as an automated test, so you shouldn't need to do anything other than run it, and the results will be logged in a file named `margins.log`. Note that it could take a while, because it uses `DECRQCRA` queries to read the screen content when checking the output. But it outputs the results of each test as they're executed, so you should be able to tell whether it's frozen for some reason. I should also mention that it highlights the results with reverse video if they've "failed", but that's just based on my best guess of how things should work. I wouldn't be surprised if the real terminals behave differently from my expectations. Also note that some of the operations were only supported on the VT510 and above, so you can definitely expect to see failures for those if testing on a VT420. I think that includes `HPA`, `HPR`, `VPA`, `VPR`, `CNL`, `CPL`, `CHT`, and `CBT`. So @KalleOlaviNiemitalo, if the test is running really slowly, and you want to save some time, feel free to comment those ones out. You'll find all the test groups listed at the bottom of the script, so for example, you can comment out the `test_hpa()` call to skip that particular group.

claunia commented

2026-01-31 06:42:25 +00:00

@j4james commented on GitHub (Mar 6, 2023):

I had some spare time this weekend and was able to make a serial cable to connect VT520 to Linux (RPi). Then I downloaded your .py script and ran it. It runs pretty long, so I had to cancel it at some point (esp. when it was filling up the screen with letters and doing some text cutting), but I did notice output in reverse meaning (according to the opening comments in the source code) that some assumptions were not met. Anyways, I'm not exactly sure how to share the results with you. I can take a video on my phone and then send you a link.

@al20878: Thanks for giving it try. I probably should have explained that it switches to a second page for some of the tests, where it fills the screen with characters and then performs various operations on that content. When each test is finished, it switches back to the initial page to output the results. On a slow connection it's probably going to seem like you're on the second test page for most of the time, and you may not even notice the results page until the very end.

Anyway, it's not important that you see the results, and you don't need to take a video, since it writes everything to a margins.log file. Even if you stop the test early, there should at least be a partial log. If you could upload that here I can see if it's doing something meaningful.

@j4james commented on GitHub (Mar 6, 2023): > I had some spare time this weekend and was able to make a serial cable to connect VT520 to Linux (RPi). Then I downloaded your .py script and ran it. It runs pretty long, so I had to cancel it at some point (esp. when it was filling up the screen with letters and doing some text cutting), but I did notice output in reverse meaning (according to the opening comments in the source code) that some assumptions were not met. Anyways, I'm not exactly sure how to share the results with you. I can take a video on my phone and then send you a link. @al20878: Thanks for giving it try. I probably should have explained that it switches to a second page for some of the tests, where it fills the screen with characters and then performs various operations on that content. When each test is finished, it switches back to the initial page to output the results. On a slow connection it's probably going to seem like you're on the second test page for most of the time, and you may not even notice the results page until the very end. Anyway, it's not important that you see the results, and you don't need to take a video, since it writes everything to a `margins.log` file. Even if you stop the test early, there should at least be a partial log. If you could upload that here I can see if it's doing something meaningful.

claunia commented

2026-01-31 06:42:25 +00:00