lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev peculiar behavior


From: Klaus Weide
Subject: Re: lynx-dev peculiar behavior
Date: Sat, 10 Jul 1999 17:59:24 -0500 (CDT)

On Sat, 10 Jul 1999, Larry W. Virden wrote:

> Re: is this an old or new behavior?
> 
> lynx 2.8.2rel.1/ncurses 4.2 shows the behavior.  I don't have anything older.

Is that release 4.2, or with patches applied?

If with patches, do they include the following? (from NEWS)

990130
        + cache last result from _nc_baudrate, for performance (suggested by
          Alexander Lukyanov).
        + modify ClrUpdate() function to workaround a problem in nvi, which
          uses redrawwin in SIGTSTP handling.  Jeffrey Honig reported that
          ncurses repainted the screen with nulls before resuming normal
          operation (patch by Alexander Lukyanov).
        + generalize is_xterm() function a little by letting xterm/rxvt/kterm
          be any substring rather than the prefix.
        + modify lib_data.c to initialize SP.  Some linkers, e.g., IBM's, will
          not link a module if the only symbols exported from the module are
          uninitialized ones (patch by Ilya Zakharevich, who says that he has
          seen messages claiming this behaviour conforms to the standard.)
        + move call on _nc_signal_handler past _nc_initscr, to avoid a small
          window where Nttyb hasn't yet been filled (reported by Klaus Weide).
        + modify lib_tstp.c to block SIGTTOU when handling SIGTSTP, fixes a
          problem where ncurses applications which were run via a shell script
          would hang when given a ^Z.  Also, check if the terminal's process
          group is consistent, i.e., a shell has not taken ownership of it,
          before deciding to save the current terminal settings in the SIGTSTP
          handler (patch by Klaus Weide).
        + correct spelling of ACS_ names in curs_border.3x (reported by Bob van
          der Poel <address@hidden>).
        + correct a couple of typos in the macros supporting the configure
          --with-shlib-version option.


   Klaus


reply via email to

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