CSI s Save cursor, available only when DECLRMM is disabled (SCOSC, also ANSI.SYS).CSI Pl ; Pr s Set left and right margins (DECSLRM), VT420 and up. This is available only when DECLRMM is enabled.
So, strictly speaking, there's no conflict here. It's still damn ugly, but not as ugly as branching on the empty parameter string.
@Nudin Could you please give some more context: What problems does this cause to you, which application breaks etc.? I'm curious and would like to understand more, e.g. how severe this bug is. Whether the change broke let's say vim, or the change broke someone's in-house shell script is not the same. Thanks!
Yes, for me it were only in-house written scripts that broke. I migrated them to ESC 7 now, that works. I was surprised about this regression. Since all other terminal that I tested do support CSI s and I havn't read about ESC 7 before.
I'm in favor of reviving support for this because other terminal emulators also impelment it, and there might be other in-house scripts elsewhere that rely on it. (terminfo defines sc=\E7, rc=\E8.) I'm not sure if VTE's main developer will agree with us, we'll see :)
According to VT520 docs, SCOSC/SCORC work like DECSC/DECRC except for not saving/restoring the page (which we don't support anyway). However, it also says that SCOSC/SCORC only work in 'SCO console mode' not in 'VT mode' mode, which I take to say that you have to activate this by DECTME 13.
Since its use is apparently more widespread that it should be (for a deprecated sequence from a long-obsolete terminal, and which is not used in terminfo), I'll take the patch to re-add support for SCOSC/SCORC, and as Egmont suggests above, distinguish it from DECSLRM by DECLRMM.
It's a pity that there's no clean way of deprecating and eventually removing such features.
VTE could warn on stderr, not too many people would notice it. Or with a new API it could ask g-t to present a popup dialog asking the user to ask the maintainers of the currently running app, totally not user friendly. Or make the feature conditional to stable/unstable vte releases and then the breakage is limited to power users. Or just remove support and live with the breakage until apps catch up, again not user friendly. Or keep support practiaclly forever. None of these are ideal.
I've been thinking about a program that sits between the terminal and the first application that could at least measure what sequences are used and maybe even ask "what have you done just now" (using it's own X11/wayland connection).
This could be independent of the actual terminal implementation and of course would be opt-in. Something like debian's popcon that would allow to get measurements about usage. Of course this is evil because it would likely involve telemetry in some form.
Right, neither of these alternatives are satisfactory. The 'implement on stable releases, unimplement on unstable' option is tempting, but it probably won't make much of an impact except get us spurious bug reports, so probably I won't bother.
I've committed a fix based on your patch now. Thanks for the patch :-)
it probably won't make much of an impact except get us spurious bug reports
Depends... if we're patient enough to investigate all bugreports (like you just did #55 (closed) – where surprisingly it didn't occur to me that it could be a duplicate of this one, I went ahead and checked if we had an off-by-one at the scrolling region) and ask the reporters to forward a canned response to these apps (or do it ourselves), then we can go ahead with the stable/unstable branching.
If you think we wouldn't bother, or should focus our efforts elsewhere, then sure it's the simplest for us to keep supporting these sequences and not to fight for their deprecation/removal.