If rxvt-unicode receives a colour query via the 7-bit control sequence, it just uses a single ESC rather than the correct terminator (BEL, ST, or ESC \):
$ printf '\033]10;?\033\\'; hexdump -C ^[]10;rgb:cccc/cccc/cccc^[ 00000000 1b 5d 31 30 3b 72 67 62 3a 63 63 63 63 2f 63 63 |.]10;rgb:cccc/cc| 00000010 63 63 2f 63 63 63 63 1b 0a |cc/cccc..| 00000019 Essentially rxvt_term::process_osc_seq and the api passing a char around only handles the single char (BEL/ST) and not the 7-bit sequences. The combination of the fix in 9.31 (where rxvt-unicode starts to respond to additional OSC queries) with a recent change in tmux causing it to make OSC 10 and OSC 11 queries) results in junk being entered when attaching to recent tmux from 9.31. (The tmux commit introducing this is https://github.com/tmux/tmux/commit/a41a92744188ec5c8a8d4ddc100ec15b52d04603 and a follow-up recognises BEL as well as ST https://github.com/tmux/tmux/commit/c0031f8b8581f7fc2d75cabade596be68f85aa81) As a temporary workaround I've patched rxvt_term::process_color_seq to override resp from the caller and just use BEL; this has the desired effect but obviously overrides what rxvt-unicode is trying to do with passing the terminator up via resp. It looks like a correct fix maintaining what rxvt-unicode is trying to do would involve a larger change to use a string instead of char for resp. _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
