Update of bug #63583 (group groff):
Severity: 3 - Normal => 1 - Wish
_______________________________________________________
Follow-up Comment #8:
I no longer regard this feature change as imposing as much pressure as I once
did.
It's not that it isn't a great idea--but it's rife with complications, and one
significant mitigator.
1. There's no standard capability for hyperlink support. The sole de facto
implementation I'm aware of uses OSC 8, an escape sequence arranged for vendor
extensions by ISO 6429/ECMA-48. However there is no standard _terminfo_
capability code with which to use the _terminfo_ API to query a host system
for the capability.
2. What the foregoing add up to is that if we add a dependency on terminfo,
it won't be X/Open Curses standard terminfo, but, in practice, ncurses. Which
doesn't _inherently_ bother me; I work on ncurses. (I even made it into the
"AUTHORS" file!) But it does mean that we trade off one portability problem
for another. And the one we buy with terminfo support means either adding a
lot of "#ifdef"s or abandoning support for systems that cling stubbornly to
System V (or, god help us, 4.xBSD) curses. I'm reluctant to do either one of
these.
3. In practice, most *roff documents going to the terminal are long enough
that the user pages them. And if they use GNU _less_, they don't our help to
exercise OSC 8 features. See
https://www.greenwoodsoftware.com/less/news.661.html . That's the good news.
4. Handling constructively overstriking and hard-copy devices is a nice idea
(and their terminfo capability codes are, blissfully, well-standardized) but I
just don't perceive any urgency for them. I've heard *zero* user demand
expressed. The only person I've seen talking about a Tektronix 4014 output
device (which can overstrike constructively, but is not hard-copy) for _groff_
is me, and I'm not sure, given its graphical capabilities, that _grotty_ is
the vehicle we'd use to support it anyway.
5. Even if item (1) above weren't a problem, and _grotty_ diligently probed
for and correctly prepared output within $TERM's capabilities, programs
downstream of us in practice don't care. They don't really care about ECMA-48
and expect _grotty_ to simply behave as it always has, or as they _assumed_ it
has, perhaps based on cursory exposure many years ago.
[https://lists.gnu.org/archive/html/groff/2026-01/msg00014.html A recent
exchange I had with GNU Texinfo developers elevated the significance of this
sad reality to me.]
I had high hopes for this enhancement, but experience has largely dashed them,
like a rock to the skull of Aeschylus.
Not closing the ticket--just noting some hard facts.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63583>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
