[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Special handling for TERM=sun (was: User Agent)
From: |
Klaus Weide |
Subject: |
Re: lynx-dev Special handling for TERM=sun (was: User Agent) |
Date: |
Wed, 25 Aug 1999 13:46:12 -0500 (CDT) |
On Tue, 24 Aug 1999, John Hawkinson wrote:
> I don't believe that many other programs use bold and reverse in
> a fashion such that it is particularly important that they be
> distinguishable from each other. In lynx, however, this is very
> important.
>
> Klaus writes:
> / > | > 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 there is some ambiguity with respect to the definition of
> "combination".
Not to mention the definition of "use". :)
My understanding was, "use the combination" == "capabilities for bold and
reverse occur in the same terminfo file".
Not the only interpretation, and maybe not the most obvious, but it
is the most relevant question.
> Solaris' terminfo files do not define a capability that
> uses both bold and reverse. They define the bold and reverse
> capabilities independantly.
a) It is not really relevant whether they occur "combined" in _this_
sense, as far as I can see, only whether they both occur in a way that
a program might assume they render differently. (Lynx doesn't depend
on any combined behavior, certainly not for making important visible
distinctions, as far as I know.)
b) Strictly speaking, you are wrong (although it doesn't matter).
At least if you are speaking about combining the abstract capabilities
("bold", "reverse") and not about combined escape sequences (like
"\[[3;7m") that might be used for one capability. The only capability
defined that could possibly combine other capabilities is sgr; and the
sgr you quoted does combine "bold" and "reverse". From ncurses's
man terminfo(5): (emphasis mine)
If there is a sequence to set _arbitrary combinations_ of
modes, this should be given as sgr [...]
> The terminal itself can do reverse only,
> and when it receives the escape sequence for bold, it does reverse.
> Terminfo does not have a way to document this particular pathology.
Well, if you take seriously that it is a "terminal capability data base",
then the way to honestly describe the capabilities of that terminal
would be to not say anything about "bold" at all. Don't claim it is
supported with any escape sequence, because it isn't.
The fact that there are two escape sequences to implement the same effect
would be irrelevant; _that_ goes beyond what terminfo can describe.
But it could pick "\[[7m" or "\[[1m" or even "\[[1;7m" as the "rev"
string.
> / > 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, ...
>
> Herein we have the definition of "combination"; I didn't understand
> you to be using the word in that way. I don't know of any terminfo
> capabilities which speak to whether you can use two different SGRs on
> the same screen.
A program should be able to assume that "bold" is clearly different
from "reverse" or "underline". Otherwise these labels dont really
make sense. Heck, a program should even be able to assume that "bold"
appears as bold and "reverse" as inverse video (so that documentation
and prompts etc. can refer to it consistently), that's the point of
having these descriptions. Anything else is broken to some degree.
Of course most terminfo descriptions are probably broken in that sense,
or commonly being used in a broken way. (Prime example "vt100").
In a less narrow sense, I would accept descriptions that map e.g. "bold"
to something not-bold, but still distinguishable from all other attributes
claimed to be supported, as "ok" (aka less broken).
> / > 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?
>
> You can edit it as a workaround. Removing either the bold or reverse
> capabilities will cause lynx to be usable. It will also cause some
> other programs which use either bold and reverse to lose.
And here is the ultimate reason why "honest" descriptions are not very
popular: people don't want max. correctness, they want max. highlighting.
> I don't know of any good editting you could do.
Either make the description "honest". Which may not really give you
the effect you want, with any given program, because the programmers
never thought of supporting a terminal well that has only "reverse"
highlighting.
Or lie in a more constructive way, to get exactly the effect you want.
Unfortunately they lying may have to be program specific.
For lynx, bold=\E[7m, removing rev, and changing sgr accordingly
should give the same effect as your patch. For other programs
it would depend on what capabilites they are trying to use in which
way.
> [snippage]
> Is there some reason you're looking at ncurses instead of Sun's terminfo
> database?
Yeah, two reasons: ncurses' was the only description I had available. And
I was trying to show a more correct description.
> From "infocmp sun" on a Solaris box:
>
> [hodge-podge!jhawk] ~> infocmp sun
> # Reconstructed via infocmp from file: /usr/share/lib/terminfo/s/sun
> sun|sun1|sun2|Sun Microsystems Inc. workstation,
> am, km, msgr,
> cols#80, lines#34,
> bel=^G, bold=\E[1m, clear=\f, cr=\r, cub1=\b, cud1=\n,
> cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
> dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
> ed=\E[J, el=\E[K, home=\E[H, ht=\t, ich=\E[%p1%d@,
> ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=\n, kcub1=\E[D,
> kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kf1=\E[224z,
> kf2=\E[225z, kf3=\E[226z, kf4=\E[227z, kf5=\E[228z,
> kf6=\E[229z, kf7=\E[230z, kf8=\E[231z, kf9=\E[232z,
> rev=\E[7m, rmso=\E[m, rmul=\E[m, rs2=\E[s,
> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m,
> sgr0=\E[m, smso=\E[7m, smul=\E[4m,
This claims the terminal supports bold ("bold"), reverse ("rev"),
underline ("smul"), as well as defining a standout mode ("smso"),
and claiming support for arbitrary combinations ("sgr"). That's
far from the truth, as I said the goal seems to be to get max.
higlighting (from various programs) rather than a good description
of actual capabilities.
Compare this to the description from ncurses (only relevant caps shown):
rev=\E[7m, rmso=\E[m, rs2=\E[s,
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m,
sgr0=\E[m, smso=\E[7m
It doesn't claim to support anything but what's actually the case.
I assume the history is that this somehow descends from the Sun version,
and that non-supported attributes were just removed. Only whoever did
that forgot to also change the "sgr" accordingly, there shouldn't be
any occurence of %p6 or %p2 to be consistent. From ncurses' terminfo(5):
Not all modes need be supported by sgr, only those for which
corresponding separate attribute commands exist.
I don't know what curses implementations are supposed do in this
situations, or what they actually do.
> / > (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.
>
> That's a great theory, but I don't know what the change would be.
I am glad you find my theories great. :)
> Additionally, even if Sun made a change in Solaris 8, I don't think it
> would be reasonable to expect administrators of Solaris 2.5, 2.6, and
> 7 to make all those changes. Certainly in MIT's distributed
> environment, it's very easy to provide software that someone can run
> on any Solaris machine, but very hard to make sure that everyone has
> made a change to their terminfo database -- it would involve requiring
> hundreds of people to make changes.
So they put binaries in shared filesystems, but not terminfo descriptions
which should be much more system independent and mostly just waste space
(if a full set) I've got to believe you, but it doesn't make any sense
to me...
----
This is gettting way too long... more later, maybe.
Klaus