Re: LYNX-DEV -color/-nocolor development confusion

[Klaus Weide]

On Tue, 22 Jul 1997, Foteos Macrides wrote:
> Klaus Weide <address@hidden> wrote:

> >It should be obvious that we are talking about lynx built with slang,
> >as far as the fotemods code is concerned, since otherwise there is no
> >color support.
> 
>       Yes, it should be obvious, but your earlier message didn't
> appear to be taking that into account.

Ok, to try to make it clear again: as far as the fotemods code is
concerned, I am talking about the case where slang is used.  When I am
talking about the development code, I have in mind all cases where
color is supported, and try to say (probably unsuccessfully...) when
I mean either the color-curses or the slang case.
 
> >               Also I am not concerned about anonymous users here.
> 
>       Perhaps not, but you should be concerned about them.

We seem to agree that nothing should change for them, as far as saving
options or preferences across sessions is concerned.  So whatever I
write below has an implied "For anonymous users...".

>       My indent is that color support will be turned on if the
> -color switch is used, if the COLORTERM enviroment variable is set,
> or if slang's SLtt_get_terminfo() decides that this is a color-capable
> terminal, even if show_color=off is in the .lynxrc file.  It is also
> my intent that users with personal accounts, but not necessarily shell
> accounts, and not necessarily able to include the -color switch or
> to get a sysadmin to fix up a bad terminfo/termlib entry for their
> most frequently used terminal, be able to save show_color=on in
> their .lynxrc file, and have that act like the -color switch. That
> means that if, on occassion, they connect with a non-color terminal,
> they must invoke the 'o'ptions menu and set "show color (&)" OFF.
> Conversely, if on some occassion they inadvertantly end up saving
> show_color=on in their .lynxrc and normally connect with a non-color
> terminal, they must acquire sufficient understanding of how Lynx works
> to know that they should invoke the 'o'ptions menu to set and save it
> back to show_color=off.  It is also my intent that for anonymous accounts,
> the default "off unless SLtt_get_terminfo() thinks it should be on"
> behavior be retained, that when it's wrong about the user not having
> a color-capable terminal they simply invoke the 'o'ptions menu and
> turn it on, but that they not be able to save that setting, and thus
> change the "off unless SLtt_get_terminfo() thinks it should be on"
> behavior for other anonymous users.  I think those intentions are
> realized in tonight's update, but if not, non-lacking bug reports are
> welcome.

Thanks for the clarifications.  It was not clear to me before that your
intent was that SLtt_get_terminfo() should override a saved show_color=off.
(Or rather, that a saved show_color=off doesn't do anything.)
The text you added to the help files led me to believe otherwise.

I have not found any bugs: as far as I have seen the fotemods code does
now what you intend it to do.

I find the behavior unintuitive and hard to explain, but of course
you may disagree.  Also, you are only concerned with the color support
by slang in the fotemod code; I am looking at the show_color stuff in
your code and trying to figure out how that can be transferred to the
development code, with its color-curses support, without making the 
behavior too inconsistent between slang-compiled and color-curses-
compiled binaries.

I agree that your implementation of saving show_color is an
improvement for the group of users you mention.  (But only if their
problem is turning color ON, not if they have problems turning it OFF
which may also happen.)  But it also adds some inconvenience, and not
only for those users who benefit from it.  An unintentionally saved
show_color=on would inconvenience also those users who do have correct
terminfo/termlib entries, and/or who connect to dialup or telnet sites
which are set up well - if they sometimes need color turned off.
That inconvenience may be minor (a visit to the 'O'ptions Screen),
and not apply to most users (since most probably always use the same
kind of terminal type), but I still don't like it.  It also makes lynx
act differently from other slang and (n)curses applications, for which
it is customary that they obey terminfo/termlib entries in deciding
whether to use color or not (rather than saving a user preference for
this).

*For the development code*, if we want to have the benefits (for some
users) of saving show_color: With color-curses, if using a saved
show_color should make any sense, i.e. have any effect, its semantics
would be different than in fotemods (since with the current curses
color support, one cannot "force" color on for just any terminal
type).  That probably means that a saved show_color:OFF would always
force color OFF (like today's -nocolor flag), and would be different
from the default.  For consistency then, and also just for symmetry of
the "show color" option with slang, saving show_color:off should have
the same "forceful" effect when the development code is compiled with
slang.  This in turn would make the inconvenience effect worse,
because one could now have lynx come up with color OFF when it is not
expected.  I think the best solution would be to give the user a
choice whether the current state of "show color" should be saved as an
override for future sessions when '>' is done.  I don't know yet
(maybe never will :) ) what's the best way to do that.

    Klaus


;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;