Skip Menu |

This queue is for tickets about the podlators CPAN distribution.

Report information
The Basics
Id: 131124
Status: resolved
Priority: 0/
Queue: podlators

People
Owner: RRA [...] cpan.org
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

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



Subject: Pod::Text::Termcap fallback defeats module's purpose
Date: Mon, 2 Dec 2019 10:52:05 +0000
To: bug-podlators [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
Pod::Text::Termcap is an excellent idea, in principle providing a great deal of terminal portability. But that portability is compromised by the module's "fallback" behaviour of using ANSI escape sequences wherever termcap didn't supply a sequence. The ANSI escape sequences are not sequences that work everywhere, and so are not suitable for use as a fallback. If termcap didn't supply a sequence for (say) bolding, then it means either the terminal doesn't have a sequence for bolding, in which case the ANSI sequence is wrong, or termcap has no knowledge of the terminal, in which case you have no idea whether the ANSI sequence would work. Mangled output is likely to result, and the caller of Pod::Text::Termcap has no opportunity to avoid this breakage. This defeats the entire purpose of the module. The "fallback" behaviour should be entirely removed from the module. Where termcap doesn't supply a sequence, it must give up on using that type of highlighting. -zefram
Subject: Re: [rt.cpan.org #131124] Pod::Text::Termcap fallback defeats module's purpose
Date: Mon, 02 Dec 2019 10:29:05 -0800
To: "Zefram via RT" <bug-podlators [...] rt.cpan.org>
From: Russ Allbery <rra [...] cpan.org>
I think I agree with the overall bug report. "Zefram via RT" <bug-podlators@rt.cpan.org> writes: Show quoted text
> The "fallback" behaviour should be entirely removed from the module. > Where termcap doesn't supply a sequence, it must give up on using that > type of highlighting.
What do you think should be the behavior on systems without a termcap database? I could go either way. I assume you're okay with the fallback for screen width. -- #!/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 #131124] Pod::Text::Termcap fallback defeats module's purpose
Date: Mon, 2 Dec 2019 19:41:05 +0000
To: Russ Allbery via RT <bug-podlators [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Russ Allbery via RT wrote: Show quoted text
>What do you think should be the behavior on systems without a termcap >database? I could go either way.
Depends on whether $ENV{TERM} is populated. If it is, with normal terminal type names, then you could recognise some of the more common ANSI-escape-using ones, and use the ANSI escapes on that basis. If $ENV{TERM} is not available, then there might be some platform-specific way to determine what kind of terminal you're faced with, and again you could use built-in sequences based on that source of knowledge. But in any case the ultimate default, if you can't positively establish what sequences the terminal uses, has to be to not attempt highlighting. What systems are you aware of that don't have a termcap db? Show quoted text
>I assume you're okay with the fallback for screen width.
Oh yes, there's not much else one could do there. -zefram