Follow-up Comment #3, bug #60666 (project groff): My design and implementation thoughts.
1. As suggested earlier, I think we want two device control keywords. One, "osc8" to enable/disable this feature. The other, to actual direct the output of the link, I think we should call something more obvious, like "link". Advantages of this include (a) not having to expose yet another environment variable for this and (b) making the device control for writing a hyperlink independent if its representation in the output. Consider the possibility that OSC 8 is deprecated at some point in the future in favor of some alternative mechanism. It will be misleading and confusing to tell the device 'X tty: osc8 id=foo url=bar' if the output sent to the terminal doesn't use OSC 8. 2. I'd cause SGR disablement (whether by -c option, "sgr" device command, or GROFF_NO_SGR environment variable) to also implicitly disable OSC 8; we don't have any way to support these links in the legacy output format. If the many fans of backspaces in BSD world can come up with a statistically-unlikely sequence of backslashes and underscores with which to embed hyperlinks, then we can revisit this question, but I think it's unlikely. Moreover, if people share Ingo's concern that SGR itself constitutes a security vulnerability, then I can't imagine that URL embedding would arouse even more agitation. So I'd lose the last chunk of the diff entirely. 3. While I personally prefer the "char const" form of declaration over "const char" because it is more regular, it is not idiomatic in the groff source tree and Ralph Corderoy's and my suggestion to migrate was ill met on the groff mailing list about three years ago[1][2]. Miscellaneous factors include: 90. I think it's habit that keeps people using the 7-bit forms for ISO 6429/ECMA-48. CSI and OSC are both well-defined C1 controls and have been for decades. I'd kind of like to make grotty(1) emit them. This will probably turn up a lot of terminal emulators that don't support them. :-/ Maybe an "8bit" device control command is also in order. But this is out of scope. Comments and disputation welcome as always. Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2018-05/msg00028.html [2] https://lists.gnu.org/archive/html/groff/2018-05/msg00042.html _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?60666> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
