lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: size_change code


From: Klaus Weide
Subject: Re: lynx-dev Re: size_change code
Date: Wed, 10 Mar 1999 09:09:28 -0600 (CST)

On Tue, 9 Mar 1999 address@hidden wrote:

> In a recent note, Webmaster Jim said:
> 
> > Date: Tue, 9 Mar 1999 11:54:24 -0500
> > 
> > Complete success would mean the full page as resized looks like it would
> > if Lynx started at that size. I have tried combos of ^R, ^W, ^L without
> > being able to get a usable screen after resize. The main symptom is
> > that moving from link to link will land the cursor in the wrong place,
> > redrawing text in the wrong position during the move.
> > 
> I don't experience even a "partial" success; more like an incomplete
> failure on either Solaris or OS/390.  After I resize the screen,
> ^R and ^L simply allow me to alternate between two different
> versions of garbled screen.

Do these failures also occur when making the screen smaller, or only
when making it larger than the initial size?

> And this is complicated even more because on startup Lynx (or perhaps
> curses) fully respects the settings of environment variables LINES
> and COLUMNS.  I find COLUMNS particularly useful when I want to format
> a document to fit a particular printer; I'd dislike to see its
> effectiveness eroded.

On the other hand, for me on linux setting LINES or COLUMNS environment
variables doesn't do anything.  Nor should it: that's what `stty rows NN'
or `stty cols NN' are for, in case I really want to fake the screen size.
I'd dislike to see *this* eroded, only to recognize some (on this system)
unnecessary environment variables...

I can't see any place where the lynx code checks for LINES or COLUMNS in
the environment.  So it must be either the curses library code that
checks them, or setting them could have the size effect of changing
the termios (or equivalent) size info (a shell could do that, but I
don't know of any that does).

> So, how should SIGWINCH interact with
> LINES and COLUMNS?  Should catching SIGWINCH override and reset
> the settings of LINES and COLUMNS on entry?  Should SIGWINCH be
> honored only if LINES and COLUMNS were unset on entry?  Are there
> useful intermediate alternatives?

The most useful behavior for me is if lynx continues to act as it does
for me on linux with ncurses 4 - ignore the environment, they just
duplicate information that can be gotten by system calls.

Maybe the solution for those folks where resizing does not work is
to *unset* LINES and COLUMNS before lynx starts.  As long as
HAVE_SIZECHANGE is defined, lynx should (eventually) figure out the 
screen dimensions.

    Klaus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]