Follow-up Comment #4, bug #68668 (group groff):
At 2026-10-13T12:44:13-0400, Ingo Schwarze wrote:
> Follow-up Comment #3, bug #68668 (group groff):
>
> The original submission makes sense to me. "Embedding hyperlinks in
> documents intended to be typeset or electronically formatted" is a
> reasonable semantic purpose. The basic design of the man(7) .UR/.UE
> macro also makes sense. I did not review the details of the macro
> design at this point, but even if there should be minor design defects
> (i'm neither saying there are nor there aren't), uniformity of design
> across macro languages is also of value because it helps users more
> easily learn different macro languages, so it may or may not make
> sense to copy specific minor design defects from one language to
> another.
>
> However, i object to almost all the rest of comments #1 and #2.
>
> The concept of a URI as defined in RFC 3986 ("A Uniform Resource
> Identifier is a compact sequence of characters that identifies an
> abstract or physical resource.") is so broad that it is essentially
> unusable in the present context. That concept is obviously not useful
> for semantic purposes because it lumps together vastly different
> classes of things and concepts under a single term. It might arguably
> be useful for purely technical purposes (as opposed to semantic
> purposes), most notably to establish common parsing rules for a wide
> range of very different classes of things and concept - except that
> RFC 3986 is an abject failure even in that purely technical respect
> because it delegates parsing rules to scheme-specific sub-standards.
> So, in a nutshell, RFC 3986 neither has a clear purpose nor does it
> establish a formal handling of that essentially undefined purpose.
>
> The concept of a URL as defined in https://url.spec.whatwg.org/
> suffers from essentially the same ailments, in some ways in an even
> worse manner. While RFC 3986 at least tries - but essentially fails -
> to define its purpose (see above), the URL living standard does not
> even _attempt_ to specify what the purpose of a URL is, see the
> introductory paragraph "Goals" which is exclusively concerned with
> parsing technicalities, not saying anything about semantics.
> Traditionally, the term "URL" was thought to be narrower than,
> designating a subset of, the term "URI"; the living standard appears
> to intend to reverse that relationship: while RFC 3986 at least gives
> a definition at all - even though an absurdly broad one - the living
> standard places no limitation whatsoever on what a URL might be,
> arguably making it even broader, but certainly making it somewhere
> between ill-defined and undefined. Note that the living standard is
> intended to supplant the existing RFCs as a whole, and for that
> purpose, it would have to define the terms and purposes now defined in
> the RFCs, but it doesn't.The foregoing battles are better fought with people who can do something about them. _groff_ can't. > I regard the approach "groff should handle URIs and URLs in a uniform > way" and then rushing to implementation proposals without even > considering questions of language design as utterly misguided and > short-sighted. That's a pretty grave insult to groff man(7)'s `UR`/`UE`, which has been around for 17 years, and groff mdoc(7)'s `Lk`, which has been around...let's see--huh!--apparently for 25 years. https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=058f72af832fc68488d33cd09ec819e5c560fa09 ...at least. I didn't bother checking if `Lk` had been bolted onto the 4.4BSD mdoc that groff had been using prior to that commit. While I've found a couple of aspects of groff man(7)'s 2009 innovations worthy of insult, on the whole I think they addressed real demands, and even people who haven't adopted them have wondered how to get at the functionality they offer. For example, the GNU findutils developers have been hankering for that sweet, sweet hanging indent on a command synopsis paragraph. https://cgit.git.savannah.gnu.org/cgit/findutils.git/commit/?id=3c2af8a185e0e290b4c3cdf701a832020860b370 groff 1.20's resurrection of Ninth Edition Unix's `EX`/`EE` for examples was a solid move. `SY`, `YS`, and `OP` were developed with insufficient consideration for the needs of man sections 2 and 3--and `OP` with evident lack of attention to GNU long option syntax, a baffling thing to overlook in 2009--but they did attack problems that man page authors still struggle to accomplish with more primitive means, eschewing these macros (either deliberately due to ignorance, as the LDP's "Man Page HOWTO" turned to hard stone in 2002), and usually with results that format badly if the output device doesn't look just like the author's. > Which kinds of resources need to be semantically represented in which > macro languages? Is the set of useful resource classes the same for > all macro languages, or are there any language-dependent distinctions? > Which kinds of resources can usefully be represented in different > output modes? Are there any language-specific considerations in the > latter respect? Why do we care about any of this? To groff, a hyperlink is a character sequence (ideally encoded exclusively in ISO 10646 code points from 0x21 to 0x7E, and possibly using percent-hex escaping even for some of those). 3 output drivers (grotty, gropdf, and grohtml) support a concept known variously as "link text" or "hot spot" that associates this character sequence with a region of the formatted page. How we express that association varies by output driver. 1. grotty encodes it using ECMA-48 OSC 8 escape sequences. 2. grohtml brackets it with HTML `a` elements. 3. gropdf...no idea, man, ask Deri. What an application _does_ with that character sequence is not our concern. > Given the failure of RFC 3986 to usefully delimit its own scope, i see > a need to define the semantic scope of what the to-be-designed > trans-language groff macros - possibly including .UR - are supposed to > cover. The word "hyperlink" in the title of this ticket might be a > (half-conscious?) attempt at doing that. However, the term > "hyperlink" seems to need clarification in the present context. Which > kinds of hyperlinks are useful for typesetting and electronic text > formatting, and why? For example, we might adopt a naïve definition > of the term, for example similar to what Wikipedia currently says: "In > computing, a hyperlink, or simply a link, is a digital reference > providing direct access to data by a user's clicking or tapping." > That would seem like a useful choice to me, but in that case, mailto: > URIs fall outside the scope by a wide margin. We might also adopt a > more formal definition, for example from RFC 8288 ("This specification > defines a model for the relationships between resources on the Web > ('links')"), again putting mailto: URIs firmly out of scope - besides, > i deem RFC 8288 too formal and complicated for our purposes. So, what > are we actually talking about, and what should we be talking about? I propose that we talk solely about what I outlined above. A "URI" or "URL" is a character sequence that we associate with a region of a formatted page. The rest is not our problem. > Let me try to approach the topic from the opposite side, from > specifics rather than from generalities. Whatever we do, it seems > clear to me URIs in the http:// and https:// schemes need to be > covered (at least simple ones - some http[s]:// URIs can be so > complicated that their usefulness in typesetting becomes dubious at > best). It is also clear that some macro languages can usefully > provide markup for email adresses. The man(7) and mdoc(7) languages > are example of languages already providing such semantic markup. > However, i will argue that using URIs syntax for email adresses does > not make sense, in particular not in a typesetting and text formatting > context, and in particular not in the way it is officially defined by > RFC 6068 which is complicated to the point of absurdity and feels like > it is designed almost exclusively with the intent of facilitating > social engineering and phishing attacks. On to of that, the dominant > practical use case of mailto: URIs, unless i'mmissing something, is > embedding email addresses in web pages typically served via HTTP[s], > with the intent that users can click on such mailto: URIs in order to > send email. I very strongly disagree with that use case for multiple > reasons. Just as one example, while it is technically possible to > instruct web browsers to invoke (some) external email programs, the > practice encourages users to send and receive email in a web browser, > which is utter madness and about the worst security nightmare > imaginable. If _users_ don't want to mark up email addresses as hyperlinks, they are at liberty to refrain from doing so. `UR` and `UE` are simply convenient names, admittedly suggestive of UR{I,L}, that we use to permit expression of the association I presented above. You seem to have quite an animated objection regarding the semantic conclusions to which people might leap from that "suggestive naming". I suggest in turn that you are overexcited. We can dial back a little on the use of the terms "URI" and/or "URL" when _documenting_ these macros, I reckon in favor of "hyperlink", a concept that people feel they understand, but we'll still need to point people _somewhere_ so that they understand what a hyperlink character sequence _looks like_, so that they can input one that is likely to work as they expect. Such character sequences still need to be expressed in the *roff language, a point that escapes many people; for example, they forget that the hyperlink might get rendered as text and consequently that the wrong kind of hyphen might show up. groff_man(7): Prepare arguments to MR, MT, and UR for typesetting; they can appear in the output. Use special character escape sequences to encode Unicode basic Latin characters where necessary, particularly the hyphen‐minus. > So there are very good reasons of both semantic and technical nature > to *not* handle email addresses with the same machinery as web > hyperlinks: semantically, they are not hyperlinks because they cannot > be used to retrieve data, and technically, they are best handled with > entirely different programs and protocols. I see no reasonable > motivation whatsoever to handle web hyperlinks and email addresses in > any similar way. That some people defined excessively generic terms > so broad that they can subsume everything and the kitchen sink is not > a reasonable motivation to wish for a uniform handling of apples and > oranges. I think that sometimes the "scheme" part of a hyperlink will be implicitly understood. Hiding the "mailto:"; prefix is only one application of that principle. Being indifferent to HTTP vs. HTTPS transport is another. > Branden's complication of proposing a proposing an additional > "suppress-scheme" flag is purely due to starting from an excessively > complicated framework that isn't adapted to the specific tasks at hand > and then piling afterthoughts on top trying to resolve the artificial > complications caused by the wrong approach to the task. Piffle. > So, let's step from the unhelpful concept of URIs or URLs and instead > ask: What exactly is the task we are tying to solve here? Web > hyperlinks? Email addresses? Anything else - if so, what > specifically? See above. > If it turns out there is a list of five things we want to do, then > *maybe* they can usefully be unified to some degree, or maybe not, > depending on the details. And that, ladies and gentlemen, is how mdoc wound up with over 100 macros in its API. I _don't_ propose adding `Ur`/`Ue` to groff mdoc, as a matter of fact, and you'll observe that neither Deri nor I mentioned mdoc. That package already has `Lk` and `Mt`. If you'd like to further effloresce mdoc's macro name space to cover four or five more categories of semantic thing that can hyperlink, you have _mandoc_(1)'s users upon which to experiment. Or, if you'd prefer a coordinated approach, the _groff_ mailing list is sitting right there awaiting your proposal. > I'm pretty sure that arguing about URIs or URLs in the abstract can > only cause confusion and complication and won't help at all. I'm pretty sure you're wrong. Let's schedule this fight for the _groff_ mailing list after I get 1.25.0 finalized. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68668> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
