reset after binary data

[Martin von Gagern]

Hi Andrei!

Your mail was suspected spam here, and I only found it now.

Thanks a lot for your investigation of the issue!

Andrei Paskevich wrote:
> rxvt-unicode does not and, I guess, should not reset reverse video 
> on reset. What it does, though, is resetting its internal reverse 
> video state flags.

Why should it not reset reverse video at the reset? I believe it should.

> Instead of deleting the line at [screen.C:242], one could check 
> rvideo_bell at scr_reset() and, if raised, stop the timer and call 
> bell_cb manually. Though I don't see too much sense in it.

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.

There are a few other places where scr_reset might be called, and I'm
not yet 100% certain that in every such case either rvideo_state is
already false or the gc and other stuff is in a valid state. I guess
they should be, especially as zero initialization initialized those
booleans to false. As having rvideo_state change without colors getting
swapped seems always a bad idea to me, placing it in scr_reset instead
of scr_poweron (as I intended first) seems the better alternative to me.

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.

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. As far as I can
tell, the linux console doesn't respond to \x05 in any way.

Greetings,
 Martin von Gagern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rvideo.patch
Type: text/x-patch
Size: 843 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20070817/2586d046/attachment.bin>