Hi Colin,
At 2025-08-26T22:21:09+0100, Colin Watson wrote:
> > .if \n[an*is-output-terminal]) \{\
> > . if '\?\V[TERM]\?'gnome-terminal' .nr an*can-hyperlink 1
> > . if '\?\V[TERM]\?'some-other-terminal' .nr an*can-hyperlink 1
> > . if '\?\V[TERM]\?'yet-another-terminal' .nr an*can-hyperlink 1
> > .\}
>
> I don't think that works. When I start a gnome-terminal instance, I
> have TERM=xterm-256color. (See VTE_TERMINFO_NAME in
> https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/vtedefines.hh.)Yeah, Egmont Koblinger (and, apparently, "desktop environment" developers generally) and Thomas Dickey are at loggerheads over this. https://invisible-island.net/xterm/xterm.faq.html#other_versions I think Thomas has the correct side of the argument. Terminal emulator developers have shown that they can't be trusted to perfectly emulate other emulators, or even hardware devices. (If you don't think video terminals merit the term "complex", ask the author of your pager.) (Heck, hardware terminal _manufacturers_ showed that they couldn't be trusted to fully validate their devices' ROM chips before going into production.) I've never heard of a line of dumb terminals being recalled, however, so I guess that industry pulled off the capitalistic optimum. Nor should terminal emulator developers necessarily try; Thomas deliberately omits some DEC VT-series features due to difficulty, lack of demand, or dubious utility. I own and operate a DEC VT525. I don't need xterm(1) to provide its multi-session support, ADDS Viewpoint emulation, or a keycap remapping feature. (Authentic simulation of the device's dog-slow color inversion operation, as for a visual bell, would be most undesirable; fortunately, xterm implements a veritable randy greyhound.) > There are a couple of GNOME_TERMINAL_* environment variables set, but > the source code says they're private variables used for internal > communication. I suppose one could check for VTE_VERSION, and VTE is > the component of gnome-terminal that actually implements OSC 8 anyway. Maybe. Or I could just not undertake this hack and see if/when any patches come in, contributed by users of the terminal emulators in question. Maybe they won't; maybe such people don't really care about OSC 8 hyperlink support. > > I'm not in love with this; I think it solves the wrong problem--a > > terminal's _type name_ is not what determines whether it has a given > > capability. It's terminfo's (and the dead-but-unburied termcap's) > > job to maintain knowledge of each terminal type's capability > > repertoire. > > > > But for getting over a hump while the community sorts out its > > direction on this matter, it's good enough. > > I guess I might reluctantly agree. I do worry that it will just > ossify a temporary hack, though, and potentially having to keep track > of all the stuff in https://github.com/Alhadis/OSC8-Adoption seems > pretty tedious; it might not even be possible to detect all of those > via the environment. I agree. If I change groff in this respect, I expect the feature to be community-maintained--meaning, if you want the whitelist extended, submit a patch. I tested the OSC 8 feature with two terminals initially: gnome-terminal(1), to ensure that grotty(1) worked correctly with a terminal that _does_ support that escape sequence, and xterm, to ensure that grotty worked correctly with a terminal that didn't. Since then I've observed that the Linux VT operates "correctly"; it silently discards well-formed escape sequences that it doesn't support. That leads us back to Helge's problem and the origin of this thread. If I don't do something about this in groff, speaking as Debian's upstream of its package, then I expect there'll be more pressure from users on you to customize "man.local", or to hack up man-db in some way. Let me know what I can do to minimize the pain. (For those wondering, I didn't implement OSC 8 support in groff for its own sake; I wanted the formatter to support bookmarks and hyperlinks for man(7) documents rendered as PDFs. grotty came along for orthogonality and because a satisfactory feature specification existed.) Regards, Branden
signature.asc
Description: PGP signature
