hmm. It's supposed to work. However, for background: most of the changes from 244 are restructuring changes (actually, making structs for the index of line-data). So before, I had something like
unsigned char *a;
unsigned char *b;
unsigned char *c;
unsigned char *d;
and now it's a struct which can have different pointer types than unsigned
char *.
The enable-fifo-lines option turns on/off a modification which lets the
saved-line area be a separate memory buffer from the visible-lines. In turn,
that saved-line area is accessed as a circular buffer.
Because of the way saved-lines and visible-lines were all one array, the new
scheme has several special cases - and up to this point, I've been assuming the
problems lie just in that chunk - particularly since more than half of the code
related to just enable-fifo-lines is in the resizing logic.
However - in that "most of the changes" chunk, it may address memory
differently, and we may be looking for a subscripting error, etc.
If I were able to reproduce this, I'd build xterm using the --enable-trace
option, to see if that gave me more information. Besides writing to
Trace-parent.out the display information, it turns on several assert's
(which may catch the problem a little earlier). There's a little more
trace that could be turned on by #define'ing OPT_TRACE to 2, though I'm
not sure if that's needed. But that's where I'd start - to find
xterm's sizes for the buffer.
--
Thomas E. Dickey <[email protected]>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
