Re: X-Term rows value off?
Re: X-Term rows value off?
- Subject: Re: X-Term rows value off?
- From: Randy Ford <email@hidden>
- Date: Tue, 20 May 2003 21:09:00 -0500
On Tuesday, May 20, 2003, at 03:19 PM, robert delius royar wrote:
Pine appears to be issuing a "glass-tty" escape sequence something like
move to the last row of the tty; /* e.g. 56 */
while current-row < total row-3 { /* e.g. 54 */
erase row
move up 1 row
}
But the library code appears to be responding by treating the move to
last
row as a move to last row as though the last row were the number
requested
in -geometry (e.g. 55), not the number actually created (e.g. 56).
But Pine
is assuming that the last row is the actual last row (56). So the
deletes
delete rows 55, 54, 53. Pine assumes the cursor is now positioned on
line 54
and begins redrawing (actually just fprinting to stdout). But that is
not
the line the cursor is on. I can actually see the effect right now. I
modified the Pine code so it thinks the window is one less than it is.
It
has issued the commands to redraw the status info and has drawn the
info in
the actual physical last line of the window and the line above. I
know this
is how the program thinks about glass-ttys because its screen code is
still
greatly indebted to Conroy's original MicroEmacs, and I lived in that
code
for a number of years. There is optimization in there to reduce the
number
and complexity of escape sequences. VTs had the ability to HOME to
different parts of the screen. I'm pretty sure that some code outside
of
Pine is accepting Pine's move to last line in an odd way--i.e treating
the
last line as one less than what Pine is seeing. I don't know whether
the
error is the same one that is in quartz-vm or if it is in some of the
other
routines that control terminfo. Pine uses ioctl to determine the window
size. Ctr-L always clears up the screen because it sets the sgarbf
flag.
I've loaded pine (version 4.53) via fink and I haven't been able to
reproduce the problem. My LINES variable is correctly set to one
greater than the geometry requested when an xterm is launched. My TERM
is set to color_xterm. I haven't seen the problem having started pine
in an existing xterm, or using the -e option on a new xterm with a
geometry. Can you give me specific steps to recreate the problem?
randy.
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.