reset after binary data

[Andrei Paskevich]

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:
http://cvs.schmorp.de/rxvt-unicode/src/screen.C?r1=1.271&r2=1.272&view=patch

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.

Andrei