Re: X-Term rows value off?
Re: X-Term rows value off?
- Subject: Re: X-Term rows value off?
- From: robert delius royar <email@hidden>
- Date: Wed, 21 May 2003 08:26:01 -0400 (EDT)
- Organization: An Apple OS X end user
- Priority: NEW
On Tue, 20 May 2003 about 21:09 -0500 UTC Randy Ford wrote:
>
> 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
> > }
> >
> 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?
In a standard compiled Pine on a system using termcaps or terminfo, setting
the LINES variable has no effect. It is not checked at all in the mailer
part of the program, and is conditionally checked in Pico (composer) only if
tgetnum("li") returns -1.
By changing two lines in the source code I appear to have removed the
symptom. The bug is still there--I see it right now--but it is not as
intrusive. Pine tells the cursor to move to the end of the window and do
some redrawing when it thinks the screen is garbled. The end Pine believes
it has is effectively the value returned in win.ws_rows by ioctl(1,
TIOCGWINSZ, (char *) &win). The return value always reflects the actual
size.
But system calls to position the cursor to the end of the window, still find
the real end of the window. When Pine tries to repaint parts of the screen
in those areas using its movecursor() function on a screen that is n rows
but which it sees as n-1 rows, then its absolute movement to row n-2 is to
it end-1. Right now, for example, the status lines which began in physical
rows end-2 and were two rows (leaving a blank line at the end of which Pine
was not aware) are now redrawn as the end and end-1 lines. There is now a
blank line between the first staus line and the end of the text. Once I
issue a command that marks the screen as garbage (scrolling to another page,
for example) the status lines *may* move up again--because Pine will use
what it sees as the more expensive method of redraw and recreate the screen
from the top of its scrolling region--currently the compose area. However,
sometimes the status lines remain in the last two screen lines once they
have moved there, and Pine redraws them fine--even when the screen is
resized.
That's why I wanted to know more about the quartz-vm bug--to see whether
this was a maifestation of it or of something else. I cannot find anything
in Pine's code that would explain why it sometimes gets the address of the
status area correct and other times does not.
My term is color_xterm, and Pine is 4.55 (self compiled without fink). But
the windowing code in pine has only had one change--one made last year when
I discovered that external window refresh code that kicks in when you try to
edit or spell chack with an alternate editor shadowed code in Apple's
ncurses library. Mark changed that code after I reported the bug. There
are no shadows now.
By the way, I saw the same display bug yesterday (for the first time) in GNU
Emacs 21.3.50.1. The modeline crept up the screen. I had to enter the
reset command in the Xterm to get cursor addressing back to normal.
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
Kill UGLY Corporate Radio
Is the educational establishment doing such a fine job locally that it wants
to take the show on the road?
-Gordon McLachlan
_______________________________________________
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.