Re: [BUG] Hyperlink macros: breaking should conserve the full hyperlink

[Alejandro Colomar (man-pages)]

Hi Branden,

On 2/7/22 23:57, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2022-02-07T23:12:59+0100, Alejandro Colomar (man-pages) wrote:
>> Hmmmm, groff_man(7) isn't explicit in the need for a link text for
>> .UR/.UE or .MT/.ME.
> 
> Right.
> 
>> Is it really needed?
> 
> No.
> 
>> What if the link text should be exactly the URI?  Why repeat it?
> 
> Repeat how?  In the input or the output?  In the input that is
> unnecessary, and in the output that should be impossible.

I meant output.

> 
>>>        .UR uri
>>>        .UE [trailing-text]
>>>               Identify uri as an RFC 3986 URI hyperlink with the text
>>>               between the two macro calls as the link text.  An argument
>>>               to .UE is placed at the end of the link text without
>>>               intervening space.  uri may not be visible in the rendered
>>>               document if the output driver supports hyperlinks.  If it
>>>               does not, uri is set in angle brackets after the link text
>>>               and before trailing-text.
>>>
>>>> And XFCE terminal highlights as a hyperlink _only_ the part that is on
>>>> the first line (i.e., up to 'process/').  The second part (i.e.,
>>>> 'coding'...) isn't highlighted, and most importantly, isnt' part of the
>>>> hyperlink.
>>>
>>> You might say that `UR` is "generous in what it accepts".  If it has no
>>> argument, it attempts to create a hyperlink out of the link text.  It
>>> doesn't do a very good job.
>>
>> It's actually the other way around, I think.  I provided the URI
>> (hyperlink), and I omitted the link text.  It shouldn't fail to create a
>> hyperlink, since the URI, which I provided, is sufficient and necessary
>> to create a hyperlink.
> 
> This:
> 
> .UR
> http://foo.bar/baz
> .UE

Huh, now I realize that thunderbird(1) broke my correct man(7) source
code.  I wrote the URI in the same line as .UR, but the $#!^! mailer
broke it into two lines :(

We were defending the same thing.

> 
> ...is, to groff man(7), a `UR` with _no_ uri argument and a URL as the
> link text.
> 
> Using a URL/URI as the link text has the potential for great confusion.
> 
> .UR http://real.destination.fsb.gov.ru/
> https://red-cross.ua/care-packages-for-soldiers/
> .UE

Agree.

> 
> Here are examples of UR/UE usage from groff's own man page corpus.
> 

[...]
> 
> contrib/mom/groff_mom.7.man:.UR 
> http://\:www\:.schaffter\:.ca/\:mom/\:momdoc/\:toc\:.html
> contrib/mom/groff_mom.7.man-.UE

This one is what I was using.

[...]
> 
> If we can find some cases where groff is emitting hyperlinks that it
> shouldn't, I'm keen to fix those, but we don't have any power to keep a
> terminal emulator from opportunistically hyperlinking text that _looks_
> like a URL to it.  To verify this, you can check the device-independent
> output of troff(1) by giving groff(1) the -Z option.  You will get plain
> text output that may look bewildering at first; it is documented in
> groff_out(5).  For our immediate purposes, just grep it or visually scan
> for lines like this:
> 
> x X tty: link http://www.multicians.org/
> x X tty: link

Oh, I thought that it was groff(1) emitting those hyperlinks.  I now
remember a recent discussiion, and that that is probably disabled by
default [and I don't care enough (yet) to recompile groff(1)].  No
problem then :)

Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/