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: Tue, 20 May 2003 16:19:32 -0400 (EDT)
- Organization: An Apple OS X end user
- Priority: NEW
On Tue, 20 May 2003 about 13:44 -0500 UTC Randy Ford wrote:
>
> On Tuesday, May 20, 2003, at 01:03 PM, robert delius royar wrote:
> >
> > Just a short followup. Pine doesn't expect any size. It queries the
> > (I
> > suppose ncurses) library routines to find out what size it has. It is
> > being
> > told it has 56 rows, which it does. But quartz was instructed to
> > create a
> > 55 row window. Does this mean that quartz-vm keeps a "record" of
> > window
> > sizes based on what it thinks they should be so that when a curses type
> > library tries to jump the cursor to the bottom status line the position
> > ends up indeterminate? I'm trying to figure what simple work around I
> > can install in the Pine sources on my machine to fix this until the
> > next
> > quart-vm comes out.
>
> What are you trying to work around? It sounds like pine is working
> correctly. Do you just want it to really have 55 rows? Can you just
> use a geometry of 54? That sounds like it would be easier that
> patching the source.
>
> randy.
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.
It's a minor annoyance except when in the setup and config screens. Then
it's maore of a problem because Pine cannot always determine where the
cursor is so setting a property by hitting return on the highlighted line
will set the property on the line below.
I have seen what appears to be a similar redraw bug in XEmacs in which the
message line gets cleared as soon as a message is sent, and this too
appeared with Beta 3, I believe.
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
Kill UGLY Corporate Radio
I think Time-Life should do a set of books on The History Of Time-Life
Books. There would be a volume titled "What Happens When People Run Out
Of Ideas."
-James "Kibo" Parry, in alt.religion.kibology
_______________________________________________
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.