Skip Menu |

This queue is for tickets about the podlators CPAN distribution.

Report information
The Basics
Id: 125285
Status: rejected
Priority: 0/
Queue: podlators

People
Owner: Nobody in particular
Requestors: khw [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: ParseLink inferred text may be in wrong font
If I make the link monotype, like in C<L<foo>> and it gets output as "foo in bar", the "in" really shouldn't be in monotype. Looking at the code, I don't see an easy way to fix this, so we may be stuck, but it is undesirable behavior
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 07 May 2018 17:37:47 -0700
To: "Karl Williamson via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
"Karl Williamson via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> If I make the link monotype, like in
Show quoted text
> C<L<foo>>
Show quoted text
> and it gets output as "foo in bar", the "in" really shouldn't be in > monotype.
It's not clear to me what that construct should mean. It's a rather odd thing to put in a document. (I assume you mean something like C<L<bar/foo>>.) Show quoted text
> Looking at the code, I don't see an easy way to fix this, so we may be > stuck, but it is undesirable behavior
Does anything actually use Pod::ParseLink these days? I wrote it way back when during the formalization of POD, but Pod::Simple went a different direction and has its own internal implementation. I kept it because it was added to Perl core (as part of podlators) and I didn't want to break backward compatibility, but I'm not sure if any POD parser uses it. (The formatting you describe would need to be handled by Pod::Simple; by the time it gets to the formatter, it's too late.) -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 7 May 2018 20:31:20 -0600
To: bug-podlators [...] rt.cpan.org
From: Karl Williamson <khw [...] cpan.org>
On 05/07/2018 06:44 PM, Russ Allbery via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=125285 > > > "Karl Williamson via RT" <bug-podlators@rt.cpan.org> writes: >
>> If I make the link monotype, like in
>
>> C<L<foo>>
>
>> and it gets output as "foo in bar", the "in" really shouldn't be in >> monotype.
> > It's not clear to me what that construct should mean. It's a rather odd > thing to put in a document. (I assume you mean something like > C<L<bar/foo>>.) >
>> Looking at the code, I don't see an easy way to fix this, so we may be >> stuck, but it is undesirable behavior
> > Does anything actually use Pod::ParseLink these days? I wrote it way back > when during the formalization of POD, but Pod::Simple went a different > direction and has its own internal implementation. I kept it because it > was added to Perl core (as part of podlators) and I didn't want to break > backward compatibility, but I'm not sure if any POD parser uses it. > > (The formatting you describe would need to be handled by Pod::Simple; by > the time it gets to the formatter, it's too late.) >
Hmmm. I grepped through Pod::Simple for where this happened, and when I couldn't find it, I tried podlators, and bingo. So I presumed that's how it worked. But you're right. I don't really see how it is getting called.
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 7 May 2018 20:41:19 -0600
To: bug-podlators [...] rt.cpan.org
From: Karl Williamson <khw [...] cpan.org>
On 05/07/2018 08:31 PM, Karl Williamson wrote: Show quoted text
> On 05/07/2018 06:44 PM, Russ Allbery via RT wrote:
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=125285 > >> >> "Karl Williamson via RT" <bug-podlators@rt.cpan.org> writes: >>
>>> If I make the link monotype, like in
>>
>>> C<L<foo>>
>>
>>> and it gets output as "foo in bar", the "in" really shouldn't be in >>> monotype.
>> >> It's not clear to me what that construct should mean.  It's a rather odd >> thing to put in a document.  (I assume you mean something like >> C<L<bar/foo>>.) >>
>>> Looking at the code, I don't see an easy way to fix this, so we may be >>> stuck, but it is undesirable behavior
>> >> Does anything actually use Pod::ParseLink these days?  I wrote it way >> back >> when during the formalization of POD, but Pod::Simple went a different >> direction and has its own internal implementation.  I kept it because it >> was added to Perl core (as part of podlators) and I didn't want to break >> backward compatibility, but I'm not sure if any POD parser uses it. >> >> (The formatting you describe would need to be handled by Pod::Simple; by >> the time it gets to the formatter, it's too late.) >>
> > Hmmm.  I grepped through Pod::Simple for where this happened, and when I > couldn't find it, I tried podlators, and bingo.  So I presumed that's > how it worked.  But you're right.  I don't really see how it is getting > called.
I didn't grep thoroughly enough. Now I found it, so I guess you can close this issue.
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 07 May 2018 19:45:51 -0700
To: "Karl Williamson via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
"Karl Williamson via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> Hmmm. I grepped through Pod::Simple for where this happened, and when I > couldn't find it, I tried podlators, and bingo. So I presumed that's > how it worked. But you're right. I don't really see how it is getting > called.
Pod::Simple's _treat_Ls sub is where all the (black) magic happens. The inferred link text is constructed here: # Now make up the link_text # L<Foo> -> L<Foo|Foo> # L</Bar> -> L<"Bar"|Bar> # L<Foo/Bar> -> L<"Bar" in Foo/Foo> unless($link_text) { $ell->[1]{'content-implicit'} = 'yes'; $link_text = []; push @$link_text, '"', @$section_name, '"' if $section_name; if(@ell_content) { $link_text->[-1] .= ' in ' if $section_name; push @$link_text, @ell_content; } } Then this gets passed down as an L<> element to the formatter with inferred link text already attached. Most of the formatters are going to treat explicit link text (the foo in L<foo|bar/baz>) the same as implicit. To do the formatting trick you're asking about, the formatter would either need to split out the " in " for implicit but not explicit link text (which it does look like Pod::Simple provides enough context to do), or not use the implicit link text and generate it itself with more complex formatting. It's kind of awkward to make this tweak, at least in Pod::Man and friends, because in general the code that formats C<> isn't aware of what's inside it. Basically each element is expanded to formatted text in an inside-out way, and the parent elements just apply formatting around that. I'm not convinced that formatting the entirety of C<L<foo/bar>> including the generated " in " text in fixed width is wrong. Why do you think that's incorrect? It might help to see the context where one would use such a construct. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 7 May 2018 20:53:53 -0600
To: bug-podlators [...] rt.cpan.org
From: Karl Williamson <khw [...] cpan.org>
On 05/07/2018 08:46 PM, Russ Allbery via RT wrote: Show quoted text
> I'm not convinced that formatting the entirety of C<L<foo/bar>> including > the generated " in " text in fixed width is wrong. Why do you think > that's incorrect? It might help to see the context where one would use > such a construct.
Generally monotype is used for things that are input by the user or output directly by the computer, and the "in" is not that. I don't recall seeing it except when the output device doesn't have hyperlinks, but looking at the code, I don't see how that gets suppressed.
Subject: Re: [rt.cpan.org #125285] ParseLink inferred text may be in wrong font
Date: Mon, 07 May 2018 20:10:19 -0700
To: "Karl Williamson via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
"Karl Williamson via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> On 05/07/2018 08:46 PM, Russ Allbery via RT wrote:
Show quoted text
>> I'm not convinced that formatting the entirety of C<L<foo/bar>> >> including the generated " in " text in fixed width is wrong. Why do >> you think that's incorrect? It might help to see the context where one >> would use such a construct.
Show quoted text
> Generally monotype is used for things that are input by the user or > output directly by the computer, and the "in" is not that. I don't > recall seeing it except when the output device doesn't have hyperlinks, > but looking at the code, I don't see how that gets suppressed.
Hm, but neither the "foo" nor the "bar" are directly input by the user in that sense either, right? It's a link to a section in some man page, and they just designate the page and section. C<> says to render everything inside it in a fixed-width font. I'm not sure why one would ever wrap an L<> tag in C<>, but if one does, rendering the link text (whether given directly or inferred) in a fixed-width font seems correct, since the formatted "value" of the L<> escape is that link text. -- #!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker $^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD, 00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{ rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
Per discussion, Pod::ParseLink isn't the source of this behavior. If it should change, Pod::Simple probably would need to be involved.