Implement rectangle functions (DECFRA, DECERA, etc.)
Examining the root cause why Xterm
and VTE
behaves differently in https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/318:
This one-liner is supposed to turn the entire canvas blue:
printf '\e[44m\e[H\e[2J'; sleep inf
In Xterm
it works both inside and outside of tmux
. In VTE
it works outside of tmux
, but doesn't work inside tmux
.
tmux
converts the standard way of clearing the screen (ED
) into DECFRA
(Fill Rectangular Area), i.e. something like \e[32;1;1;24;80$x
, which we don't support.
We should add support for this sequence.
Note 1:
There are some terminals which don't support DECFRA
, yet that one-liner works in tmux
. E.g. pterm
, konsole
, and also (surprise-surprise) VTE
0.74.
There tmux
converts that to a scrolling escape sequence rather than DECFRA
. I guess the reason for the different behavior of tmux
is a different response to DA1
or some similar feature query, but I haven't investigated further.
(An alternative way to "fix" this issue might be to report a set of features that don't imply DECFRA
.)
urxvt
's "correct" behavior is another, easier story since there the outer $TERM
is different, tmux
knows straight away that it doesn't support DECFRA
and goes with something else instead.
Note 2:
Xterm
(v390) allows any Unicode codepoint as parameter. If it's a zero-wide combining character then the escape sequence is a no-op. If it's a CJK then it fills twice as many cells as it should (not a behavior I'm fond of, I'm tempted to no-op again).
Does it always interpret the number according to Unicode, or does it use the current encoding? Also, what about runtime encoding changes, such as line drawing mode? To be checked.
Note 3:
screen
(v4.09.01) itself is buggy, it emits stupid output that doesn't even work in xterm
. So test this story with tmux
only. [Update: screen
's current master, which calls itself v4.99.0, works correctly.]
Note 4:
Currently I'm not aware of any real life problems this causes. The one linked above is a user configuration error (wrong $TERM
). But given the one-liner reproducer shown here, I suspect there might be real life problems lurking around that just no one has found and reported yet (they're not on newest VTE
yet).