Front page | perl.perl5.porters |
Postings from November 2021
On 11/29/21 11:14 PM, Oodler 577 via perl5-porters wrote:
> * tables can be defined in some intermediate way, but the resulting distribut-
> ed "POD" visible via "perldoc" would be a neat ASCII table contained in a
> verbatim section. And this preformatted text would be "safe" in all places
> the POD would appear.
Agree.
In support of the toolchain concept:
Given that POD can now contain Unicode, why not allow or encourage
tables using the "Box Drawing" characters (a derivative of what we used
to call the vt100 and IBM PC Line Drawing sets) as shown at
https://unicode-table.com/en/blocks/box-drawing/
For example, consider this in perlfaq4.pod:
Pictures help... Here's the C<%hash> table:
keys values
+------+------+
| a | 3 |
| x | 7 |
| d | 0 |
| e | 2 |
+------+------+
Why shouldn't this be the nicer-looking:
Pictures help... Here's the C<%hash> table:
keys values
┌──────┬──────┐
│ a │ 3 │
│ x │ 7 │
│ d │ 0 |
│ e │ 2 │
└──────┴──────┘
It is true that my (notional) DECwriter LA-36 won't nicely print that,
but even the Linux console does nowadays. It is curious that folks were
widely using line-drawing characters in the late 1970s while Perl's
standard POD today still doesn't. Given a toolchain that creates such
tables in POD files, authors wouldn't even have to look up the gyrations
to type all those funny characters. Is there any argument against this,
when (per "perldoc perlpod") POD can officially contain any
Encode::Supported encoding?
The same is true if authors want to use Pikchr or *roff's "pic" or "dia"
or whatever to create diagrams and flowcharts; given the
table/image/diagram source code attached to the module, and a
description of the filters used, that keeps distributions reproducible
and modifiable.
\\/
Thread Previous
|
Thread Next