Re: LYNX-DEV fotemods.zip update

[Foteos Macrides]

"Hiram Lester, Jr." <address@hidden> wrote:
>On Mon, 26 May 1997, Foteos Macrides wrote:
>
>> 1997-05-27
>> * Eliminated underlining in conjunction with reversing for the current
>>   link with slang, to avoid the longstanding bug of underlining being
>>   lost (and distracting color changes occurring) when that link ceases
>>   to be current and it was embedded in an underlined region of text.
>>   The attributes of the current link can be better handled in the
>>   development code based on configureable style sheets, so there's no
>>   point letting this bug ride, nor trying to deal with it through
>>   temporary internal mods, in this code set. - FM
>
>Hmm, interesting... I like the way this mod looks when in mono (just like
>standard curses), but in color, it removes a color (selected links are the
>same as a status line).  Also, the bug you refer to only APPEARS to be
>fixed with this mod.  If colors 1 and 5 are the same as is the default,
>then it looks correct.  I have 1 redifined as brightblue:black.  When I
>pass over links in color 5, they are still redrawn in color 1.
>
>Is it possible to determine if color is being used? (I know -color, but
>does lynx know it's color if COLORTERM is defined?)  If so, it might be
>nice to handle it the old way for color and the new way for mono.

        The -color or -blink switches make Lynx_Color_Flags non-zero,
but as you guessed, it stays zero if color was turned on via the
getenv("COLORTERM") check.  However, if color was turned on by any
means, then SLtt_Use_Ansi_Colors will be non-zero, so that can be
used as a check.  Today's update handles it "the old way" (with the
glitch when underlining already is being asserted by virtue of other
markup) for color, and "the new way" otherwise.


>Another strange thing I noticed is that that select popup boxes persist
>under slang (linux and HP), HP's curses, and ncurses (linux).  I presume
>this is due to the following mod:
>
>> 1997-05-26
>> * Mods of change_form_link() in LYForms.c to bypass the screen redraw
>>   on retraction of a SELECT popup if the SELECT block is DISABLE-ed
>>   or the selected OPTION was not changed.  Note that the complete
>>   elimination of the screen redraw in the 1997-05-20 development code
>>   mods, i.e., even when the selected OPTION was changed, results in
>>   the change not being made evident to the user in the retracted popup
>>   unless the screen is redrawn fortuituously (e.g., due to subsequent
>>   paging). - FM
>
>Ech!  This is bad...  This looks horrible and just causes the user to
>press ^L to redraw instead of letting lynx handle it.  The popup simply
>does not retract at all in the current fotemods code.

        Today's update gets that working in the for-slang code almost
as efficiently as with VMS curses.  The Unix curses seems brain dead
compared to the VMS curses, and doesn't restore what was there before
when you do the delwin() followed by refresh() to retract the popup
window.  I had assumed that would work for Unix curses as for VMS
curses because the current development code appeared to be relying on
it to work.  I built -0.28 on Scott's solaris, and it doesn't work,
at least not for me, with the development code either.  I played around
with it in the fotemods code on Scott's solaris, and didn't come up
with any trick to make it work.  So, for Unix curses with the fotemods
code, it again does a screen redraw whenever the popup is retracted.

                                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.
;