We do detect rxvt-unicode already so it would be fairly simple to add a feature flag to disable sending these sequences to it (add to tty-features.c and apply for rxvt-unicode in tty-keys.c). This might be a good idea since they have not fixed it.
On Sun, 10 Dec 2023, 07:34 Nicholas Marriott, <nicholas.marri...@gmail.com> wrote: > Hi > > IIRC the problem is not that rxvt-unicode sends BEL instead of ST, it is > that it truncates it to one byte, so it only sends \033 rather than \033\\ > for ST. > > Always sending BEL should work because tmux will accept either (although, > as you say, convention is to copy the terminator used on the received > sequence). > > > > On Sat, 9 Dec 2023, 21:57 Stefan Hagen, <s...@openbsd.org> wrote: > >> Tim Chase wrote (2023-12-09 21:47 CET): >> > When connecting from an rxvt terminal on my FreeBSD daily-driver >> > to my OpenBSD 7.4 server, tmux sends the CSI requesting color >> > information. But when rxvt replies, tmux ignores the reply and the >> > resulting answer dumps answer-back garbage into my session as if I >> > typed it. At a prompt, it's largely just an annoyance since I can >> > control+u to clear it; but if if the session is pointed at some TUI >> > program, the answer-back garbage can really mess with the session. >> > >> > If I'm within rxvt on FreeBSD (also v9.31), and I create a new >> > session or attempt to attach to an existing one (regardless of what >> > $TERM was set when the tmux session was started), I get the answer-back >> > garbage. If I use xterm or suckless `st`, or the rxvt from OpenBSD's >> > packages used locally it doesn't happen. >> > >> > The full conversation thread is here[1] and according to /u/sdk-dev >> > who was able to reproduce and narrow down the changes, they say >> > that it broke in this change[2] where these two lines[3] were moved >> > outside of some checks. >> > >> > As best we can tell, tmux is failing to consume the answer-back it >> > requests. >> >> Hi, >> >> I've updated my answer on reddit quite a few times, so you probably >> haven't seen the latest version. >> >> The bug here is with rxvt-unicode. The xterm specification describes OSC >> requests to be either terminated with the ST \033\\ or with the BEL \007 >> terminator. >> >> The response from the terminal should then match the terminator of the >> request. rxvt-unicode is failing to do so and always terminates with >> BEL. >> >> Tmux is doing this correctly. It sends ST and expects ST. >> >> The specification describes ST as the newer and preferred terminator, >> which was probably the reason why it was decided in OpenBSD to switch >> rxvt-unicode to ST instead of switching tmux to BEL. >> >> I don't know if rxvt is still developed somewhere, so FreeBSD could >> adopt our patch. >> >> >> https://cvsweb.openbsd.org/ports/x11/rxvt-unicode/patches/patch-src_command_C?rev=1.6&content-type=text/x-cvsweb-markup >> >> Do we want some special handling for rxvt-unicode in tmux? >> I'm not knowledable enough in this area to have an opinion. >> >> Best regards, >> Stefan aka /u/sdk-dev >> >> > Thanks, >> > -tkc >> > >> > [1] >> > >> https://www.reddit.com/r/openbsd/comments/18cxwdy/tmux_causing_ansi_colorresponse_garbage_on/ >> > >> > [2] >> > /* $OpenBSD: tty.c,v 1.434 2023/09/02 20:03:10 nicm Exp $ */ >> > >> https://github.com/openbsd/src/commit/903d1285474e6a1a8bfdc71e5c97f8037e5d801a#diff-f63cc050113818ea4ebd794e00daec9960f613b4dbd2039bed3d532c7ea8096dR373 >> > >> > [3] >> > https://github.com/openbsd/src/blob/master/usr.bin/tmux/tty.c#L373-L374 >> >>
