Re: lynx-dev lynx with -color and -lss

[Klaus Weide]

Please send your messages to the lynx-dev list; I am cc'ing this
reply.

On Sun, 18 Apr 1999 address@hidden wrote:

> Hello Klaus,
> 
> Thanks for your information, that should help to track down the
> problem.  To make a long story short, I was able to get colors
> from lynx while I was writing this e-mail. :-) Solution: use -term
> option instead of -color!
> 
> Since I'm still curious about what's wrong, I took the liberty of
> including some diagnostic messages.

There's nothing really 'wrong', but there are two different philosophies
here:
  - Try to enable color 'somehow', even if that may contradict the
    the terminfo (or termcap) information.  (slang)
    That includes allowing the user to override the assumption that
    the terminal does *not* support color (derived form terminfo).
  - Strictly believe the terminfo (or termcap) information (ncurses).

When built with slang, lynx follows the slang philosopy; when built
with ncurses, it follows the ncurses philosophy...


> > [./configure ...]
> > That should work fine, at least with a not-too-old version of ncurses.
> 
> ncurses is version 4.2.10, slang is 0.99.38.8.  I'm not familiar
> with curses at all, but I noticed something peculiar: I re-unpacked
> the lynx-tarball and configured --with-screen=slang.  This time I
> got an error message:
> 
>       [...]
>       checking for screen type... slang
>       checking if we can link slang without termcap... yes
>       checking if color-style code should be used... configure:
>       error: Configuration does not support color-styles
> 
> The message disappears if I configure for ncurses, make clean, and
> configure for slang again.  Guess make clean doesn't make that
> clean.

Color-style only works with (n?)curses, not with slang.

There may be a glitch in the configure script here, but I am not
familiar with its details.  Maybe the error would not have happened
if you had done  `make clean'  *and*  `rm config.cache'.

> > And as Tom notes, the -color flag is only for slang and isn't needed
> > otherwise (with or without color-style).
> 
> I see; I probably wasn't very clear here.  When I compile lynx
> (with or without support for lss files), the resulting binary
> doesn't support the -color command line option like the Red Had
> binary, i.e. I get an 'invalid option' error message.

The color flag is recognized if and only if lynx was compiled with
slang.  So the Red Hat binary must have been compiled with slang.
You should be able to verify that by running `ldd' on the binary.

> > If you terminal type according to $TERM supports color (well enough),
> > colors will be used.
> 
> Yes, here's the catch.  The Red Hat binary correctly identifies an
> rxvt and shows colors automatically, and in an xterm, I can start
> the Red Hat lynx with -color to get color.  My homegrown lynx, on
> the other hand, needs to be invoked with '-term=rxvt' for colors.
> I found this behavior puzzling; if you have a ready explanation
> for this, I'd be eager to hear it, otherwise don't bother -- I'm
> happy that it works.

Please review other messages on this topic, especially form the last
week or so, in the lynx-dev archives.

Your xterm terminfo file says that color is not supported, and
your rxvt terminfo file says that color is supported.  I assume
your xterm program is configured to set TERM to "xterm", and
that "rxvt" also sets TERM to "xterm".  But you can change
these if you want (make xterm set TERM to one of the alternative
types like "xterm-color", "xterm-xfree86" or whatever is appropriate,
and make rxvt set TERM to "rxvt"), by putting the right magical
incantation in the right Xresources (or similar) file; something
like 'XTerm*termName: xterm-xfree86'; see the man pages [and write
up a mini-Howto after you've figured it all out...].  You may wonder
why this isn't being done by default.  The answer afaik is for
compatibility with other systems that know only about basic xterms
without color (or other extensions): for example if you telnet
from an xterm window into a different OS (or the other way round).

   Klaus