Re: lynx-dev terminal emulators, SIGWINCH (was: Danish translation)

[Klaus Weide]

On Fri, 12 May 2000 address@hidden wrote:
> In a recent note, Klaus Weide said:
> > Possible reasons why it might not work:
[ numbers added]
> > 1. the tty doesn't get informed of the size change (stty -a wouldn't show 
> > it).
> > 2. lynx doesn't get sent a SIGWINCH.
> > 3. your curses lib overrides the handler.
> > 4. the ioctls by which size_change determines the size don't work on
> >   your system (or are not implemented).
> > 5. Lynx itself might get the new size, while the curses(or slang) lib
> >   does not become aware of the change (but this would result in different
> >   behavior, not 'completely insensitive').
> > 
> > Find out which it is, and then you or someone else can try to fix it.
> > You'll need to do some debugging.
> > 
>                     Lynx Trace Log (2.8.3rel.1)
> 
>     User message: Trace ON!
>     Window size changed from (33,93) to (42,104)               
>     Got EOF with EINTR, recent_sizechange so far is 1 
>     stop_curses: done.
>     start_curses: done. 
>     GridText: HText_pageDisplay at line 1 started 
>     GridText: HText_pageDisplay finished
> 
>     Turning off TRACE for fetch of log.
> 
> Clearly SIGWINCH got caught.  But the display wasn't reformatted.

That seems to exclude 1, 2, 3, 4 from my list.  Leaves 5.

Your trace shows that lynx gets the new size.  The lynx code updates
its idea of LYlines and LYcols (otherwisethere wouldn't be a
"Window size changed from ..." line).

But that's only half of what's necessary to display correctly for the
new size.  The display library, whether that's slang or curses, also
needs to update *its* idea of the window size.

In the case of slang, that's guaranteed to happen, since lynx uses
slang functions to determine its (lynx's) idea of the window size.
In the case of curses - well, the start_curses/stop_curses you see
in the trace are an attempt to trigger the curses implementation to
re-examine the actual size (presumable it will do that, in some way,
using the same basic functions that lynx uses - lynx can get at the
actual size, so the curses lib should be able to do the same).
See the (first) 'if (recent_sizechange) ' in LYMainLoop.c and comments
there.

If your curses lib does *NOT* update its idea of the window size -
use a better one.  Or maybe it needs to be configured in some way
(environment variables?) in order to give precedence to actual size
determined from system calls over the LINES and COLUMNS variables.

> Further:  Regardless of my actual window geometry, lynx formats the
> screen according to the settings of the environment variables LINES
> and COLUMNS.  If those variables are unset, lynx uses the default
> screen size.

I don't thing that 'lynx uses' is strictly true.  I suspect that 'lynx'
(the lynx code) uses the correct new size, while curses internally remains
unaware of the change.

> The behavior of vi is slightly different:  as long as LINES and COLUMNS
> are unset, vi uses the actual (not default) screen size and correctly
> redraws when the screen is resized.  if LINES and COLUMNS are set when
> vi is entered, vi uses those values, regardless of actual screen size
> and is oblivious to any resizing.
>
> 
> All on:
> 
>     address@hidden:460$ uname -a
>     OS/390 MVS3 07.00 02 9672
> 
> As far as I can tell, the behavior of both lynx and vi is identical on
> both OS/390 and:
> 
>     address@hidden:225$ uname -a
>     SunOS sanitas 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-5_10

You haven't said what kind of display library you use.  I expect it
is neither slang nor ncurses, in both cases.

You haven't described in detail what you actually see, beyond 'completely
insensitive'.  How exactly does 'completely insensitive' look?

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden