Re: now 2.7.1ac-0.36 (was Re: LYNX-DEV Request) (fwd)

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>On Sat, 19 Jul 1997, Foteos Macrides wrote:
>>[...]
>>      Hiram raised this issue a while ago, but it is yet to be addressed.
>> The autoconf is checking system capabilies, and setting up the build solely
>> based on those, without also providing a means for taking into account
>> lesser terminal capabilities at run time.  You see the consequences of this
>> (probably unwitting) change in design principles most dramatically in the
>> case of color handling.  If the system has color curses capability, then
>> the image will be built with that capability, and if you invoke that image
>> without a color terminal, you're up the creek without a paddle.  
>
>???
>
>I just built three versions of the 2.7.1ac-0.36 code set on Scott's
>solaris machine - with slang, with ncurses (4.1), and with the native
>curses.  All three binaries support color, since the three libraries do.
>All three fall back to using reasonable mono attributes when used with
>a non-color terminal type (tested with -term=vt100, terminal is a linux
>console), for document text.  The difference between the slang binary and
>the other two is that the first uses reverse+underline for the selected
>link, the other two use only reverse. ("underline" doesn't appear as
>underlining on my screen, but that's a different story and I have factored
>it out.)  There are differences for the status line (see below) and
>possibly on the options screen, but mostly the downgrading works, in
>my observation.
>
>What we don't have is downgrading support a terminal which doesn't
>understand any attributes, or just standout()/standend(), with the same
>binary, but then that isn't in 2.7.1 or fotemods either AFAIK - except
>via show_curser, which is there.
>
>> Back when
>> John did the original slang port, he included the -color switch to address
>> this problem (which I agree should also be in the options menu, now that so
>> many, but not all, Lynxers have color terminals).  But there's nothing of
>> that sort, nor effective automatic handling of this at run time, in the
>> color curses port.
>
>As observed, there is, and it works for me.  The original slang port
>doesn't provide any more in this respect, for downgrading to a
>less-capable terminal.  It has a -color flag, but it doesn't have
>a -no_color switch.
>
>> Moreover, it has messed up the situation for slang,
>> so that if you connect with a non-color terminal, you don't get reverse
>> for the statusline messages even with a slang built image and the -color
>> switch not set.
>
>Well, I do get reverse for the statusline, with the slang binary and
>-term=vt100.  (What terminal type are you using?)  It is the other
>two binaries where I don't get any emphasis for the statusline, and
>that should be corrected.
>
>>      The good news is that the popup stuff was merged essentially as is
>> into LYOptions.c, and if I do a temporary hack to fix up the bad statusline
>> handling, and then use "configure --with_screen=slang", the popups work
>> as in the fotemods with proper character attribute handling, so I suspect
>> the problems you describe will go away when the curses color port is thought
>> through and fixed up (plus whatever got messed up on Scott's SPARC should
>> be fixed).
>
>Not all problems have gone away.  Here are the problems I observe.
>"linux" is a term type which supports color, "vt100" is a term type
>which doesn't support color, according to the terminfo files.
>
>
>library / TERM       popup in FORM        popup in Options Screen
>==============       =============        =======================
>
>curses / linux       COLOR + BORDER       COLOR + BORDER
>
>curses / vt100       Ok                   Ok
>
>ncurses / linux      Ok                   COLOR
>
>ncurses / vt100      Ok                   Ok
>
>slang  / linux       Ok                   Ok
>
>slang  / vt100       Ok                   Ok
>
>"BORDER" means: (with BOXHORI and BOXVERT set to 0")
>In the place where the box line-drawing characters should be,
>I get y-umlaut characters (character 255, hex FF) on the screen.
>
>(Speculation: the system curses on sol doesn't understand the
>binary format of the /usr/local/lib/l/linux terminfo file.)
>
>"COLOR" means:  There are inconsistent color changes.
>When the popup first appears, lines other than the current one are
>shown white-on-black.  The selected line is yellow-on-blue (This
>is with the default colors, no change in lynx.cfg.) [except for the
>number in the case of the Options Screen which is white-on-black.]  
>After moving the selection, the now unselected line is black-on-white.
>[In the case of Options Screen popup, the number on the now selected
>line also has turned white-on-black].  Moving to an item within the
>popup with the "12g" command turns all lines white-on-black.  However,
>the spaces (one each before and after the text) always stay black.
>
>I hope Tom will look into this (and make things work not just with
>ncurses 4.x).  I am not sending the terminfo files since Tom has 
>acces to the same ones I am using.

        My emulator declares itself as vt220.
        
        The development code's statusline() in LYUtils.c has:
        
[...]
#ifndef USE_COLOR_STYLE
        lynx_start_status_color ();
        addstr (buffer);
        lynx_stop_status_color ();
#else
        /* draw the status bar in the STATUS style */
        {
                int a=(strncmp(buffer, "Alert", 5) || !hashStyles[s_alert].name 
? s_status : s_alert);
                LynxChangeStyle (a, ABS_ON, 1);
                addstr(buffer);
                wbkgdset(stdscr, has_color ? hashStyles[a].color : 
hashStyles[a].mono);
                clrtoeol();
                wbkgdset(stdscr, hashStyles[s_normal].color);
                LynxChangeStyle (a, ABS_OFF, 0);
        }
#endif
[...]

        What this means is that if the image was built with USE_COLOR_STYLE
defined, you do get a check for "has_color".  Otherwise, you get what's in
lynx_start_status_color().  Here's what's in it:

[...]
#if USE_COLOR_TABLE && defined(COLOR_CURSES)
   lynx_set_color (2);
#else
   start_reverse ();
#endif
[...] 

        What this means is that if the image was built with USE_COLOR_TABLE
and COLOR_CURSES defined, you get the actions performed by lynx_set_color(2).
Those will not work with terminals that lack color support, so you'd have
to build two Lynx images, and invoke one or the other, to have the statusline
attributes handled properly with both color and non-color terminals.  Perhaps
when you set your linux console for vt100 emulation it is still responding to
the lynx_set_color() actions, and you are not seeing the problems I described
(which still occur, despite the fixup of Scott's system headers).

        I am not aware of any curses packages which lack standout() and
standin() functions (though there might be :).  All released versions of
Lynx assume the curses package has at least those two, and will use them
as an ultimate fallback via definitions and functions in LYCurses.h and
LYCurses.c.  I've retained that fallback logic in the fotemods.  The
development code has interposed start_standout() and stop_standout()
functions with muddled logic which breaks the intended fallback behavior.
My LYOptions.c mods replaced its old, directed standout() or standin()
calls with start_reverse()/stop_reverse() or start_bold()/stop_bold()
calls (see below) that retain the intended fallback behavior.

        The intent for the LYOptions.c popups and for the binary choices
of fixed values is that the current choice be indictated via reverse or
corresponding background (not just foreground) color change, and for that
background to extend a fixed duration, determined by the length of the
longest fixed value, regardless of the length of the current choice.  It
contrast, bold or the corresponding color is to be used for choices which
in fact are invoking the line editor, and that emphasis should not extend
beyond the end of the current string, no matter what it's length.  That's
messed up in the current merged development code, as I explained in an
earlier message.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;