Hi,

> It's fixed. Thanks! (What was it? There is no description.)

thanks for verifying. I wanted to be sure that I'd found the right
place before elaborating what the problem was. The bug could be triggered
by making rxvt execute the following escape sequence:

'\e[1;19r\e[10S'

This reduces the scrolling region to lines 1-19 and then scrolls 10
lines forward. If the scroll buffer is empty, rotating it will move null
pointers into the "visible area" (because memory for each line is only
allocated when necessary) - but the allocation code didn't take the reduced
scrolling region into account, so some null pointers remained. (E.g. with a
80x24 terminal, the code would verify that after rotation the memory pointers
for display lines 14-23 were non-null instead of lines 9-18.)

The regular rxvt termcap is slightly different, and mutt uses a different
control sequence to accomplish the same result there - that's why it only
surfaced with your custom Xresource (which caused it to use xterm's termcap).

If you want to see something really annoying, have a look at my patch
(note the comment line):

] --- rxvt-2.6.4/src/screen.c
] +++ rxvt-2.6.4/src/screen.c
] @@ -853,8 +853,8 @@
]      count = scroll_text(screen.tscroll, screen.bscroll, count, 0);
]  /* XXX: Ummm, no?  care needed with [bt]scroll, yes? */
]      if (count > 0) {
] -     row = TermWin.nrow - count + TermWin.saveLines;
] -     erow = TermWin.nrow + TermWin.saveLines;
] +     row = TermWin.saveLines + screen.bscroll - count;
] +     erow = TermWin.saveLines + screen.bscroll + 1;
]      } else {
]       row = TermWin.saveLines;
]       erow = TermWin.saveLines - count;

Yes, care needed.


Regards,

Jan

Attachment: signature.asc
Description: Digital signature

Reply via email to