lynx-dev Special handling for TERM=sun (was: User Agent)

[Klaus Weide]

On Mon, 23 Aug 1999, John Hawkinson wrote:

> | > lynx-dev Special handling for TERM=sun  
> | > http://www.flora.org/lynx-dev/html/month0799/msg00882.html 
> | 
> | and don't see the need for this (while I'm aware that wscons doesn't
> | implement bold, neither does Solaris' terminfo use that combination
> | - so it seems you're fixing something that's already known to be
> | fixed)

Tom says that Solaris' terminfo doesn't "use that combination".
The only sensible intepretation of that for me is that the combination
does not occur in Solaris' terminfo files for the terminal type in
question.

> Perhaps I was unclear.  lynx w/o this patch or something similar is
> next to unusable under wscons because it implements bold and reverse
> in the same way (reverse). While Solaris's terminfo doesn't use that
> combination, 

You seem to agree, but ...

> lynx uses them both on the same screen, and you cannot
> distinguish the currently active link from any other link.

... this would mean that lynx uses the combination in spite of the
terminfo, ...

> Do you have an alternative solution to using lynx under wscons that
> does not involve editting the terminfo definition to remove either the
> reverse or bold capabilities 

... and here it seems the terminfo definition _does_ after all contain
wrong entries (or editing it would make no sense).  So which is it?
It seems indeed (also from the message containing your patch) that
Solaris' terminfo does "use that combination" (so Tom was wrong).

The terminfo for "sun" from ncurses has

   enter_reverse_mode=\E[7m, enter_standout_mode=\E[7m,
   exit_attribute_mode=\E[m, exit_standout_mode=\E[m,
   set_attributes=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m,

which seems to make sense except there is no
{enter,exit}_{bold,underline}_mode although those are used in sgr
(set_attributes).  [ Tom, is this right? ]

> (I think that is not an acceptable change
> to force users to make; 

It is also not acceptable to expect (all?) terminfo-using programs to 
know and workaround problems in description data.  The problem should
be fixed in the right place, which is the bogus description.

At least that's what it seams like to me; I am not familiar with the
specific environment, so maybe I am missing something.

You make further arguments (in the original message) about screen and
the "vt100" type:

>The rationale behind the environment variable is that if one is on
>such a lousy terminal, one is quite likely to run 'screen', which makes
>everything appear like a 'vt100'. Nevertheless, one has the same problem.
>There's no way to determine what sort of terminal the 'screen' is running
>under, nor would such a determination really be appropriate from an
>abstraction point of view.

Not being a regular screen user either, I don't know for sure, but this
seems dubious.  Does screen really make everything appear like a 'vt100',
without recourse?  I thought there were fixup mechanisms.

Exactly from an "abstraction point of view", "vt100" should mean vt100
and nothing else, and if the terminal cannot really support that then
TERM should contain something else.  More programs than lynx should
benefit from fixing it.

Finally (and back to lynx), your choice of which attribute to suppress,
and which remain being used for what, may not be the only sensible one.
Changing the terminfo description according to taste would be more
flexible than just one binary flag. (You could use underline for the
current link instead of nothing, or similar tricks).

> the only times I seem to use lynx under wscons
> are when something is serious wrong and I'm in a hurry, and expecting
> people to stop and debug weird terminfo "lossage" seems unfair).

You then have to carry a "fixed" (i.e. fixing) lynx binary with you
anyway (or have it already installed on those machines); how much more
effort is it to have a fixed terminfo file (or have it already installed
on those machines) and set TERM or -term?  Terminfo files are binary-
compatible (to the amount that it matters) afaik.

I don't say you patch shouldn't go into lynx (I leave that to Tom to
decide, he will anyway :)).  You use a generic mechanism (~Masked_Attr)
that could be used for more than your specific problem, and adds some
documentation, all good points.

   Klaus