reset after binary data
andrei at capet.iut-fbleau.fr
Fri Aug 17 16:53:47 CEST 2007
On Fri, 17 Aug 2007 at 13:49:46 (+0200), Martin von Gagern wrote:
> Stopping the timer doesn't seem worth the effort, as a duplicate
> invocation won't do any harm. If you want to catch the case of
> rvideo_mode == true as well, you'd probably want to call scr_rvideo_mode
> in scr_reset directly. See attached patch.
In fact, Marc Lehmann has already committed a patch for screen.C into CVS:
This patch sets rvideo_mode to false and leaves rvideo_state as is,
thus "reset during video bell" is not a problem anymore. Nevertheless,
we do not call scr_rvideo_mode() from scr_reset(), and this leads
to an inconsistency. Namely, if we do (with visual bell):
% echo -ne '\e[?5t' # reverse video on (rv_mode = rv_state = 1)
% reset # rv_mode = 0 but reverse video is still on!
% echo -ne '\a' # bell_cb() calls scr_rvideo_mode() which now
# turns reverse video off (as rv_mode requires)
Therefore, I believe that your patch gives a better approach: then
reset will turn reverse video off immediately (though, maybe, you
should call scr_rvideo_mode() at the very beginning of scr_reset(),
above all if's).
> I found yet another way to trick rxvt-unicode into an inconsistent
> state: run "while sleep 0.1; do echo -ne \\a; done" with both visual
> bell and fading enabled, and while the loop flickers your window, change
> repeatedly between that window and another one. Chances are that one
> swap will work on the focused colors and the matching swap on the
> unfocused set, causing both to be in reversed state although
> rxvt-unicode doesn't realize it's reversed. I guess scr_rvideo_mode
> should always flip both sets. See attached patch.
Should we do this in init.C, too, when Opt_reverseVideo is processed?
> For those 1;2c that appeared on my prompt, I now found that to be the
> answerback string which gets printed for every \x05 char in some binary
> stream. Setting the corresponding X resource answerbackString to the
> empty string solved that as well. I'm curious whether any application
> will suffer from not getting an answer to its enquiries.
Probably not, since xterm sets answerbackString empty by default.
More information about the rxvt-unicode