1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
[[!template id=gitbranch branch=jon/table_headerblock author="[[Jon]]"]]
It would be great if it were possible to support multi-row table headers in the [[plugins/table]] plugin, so you could do e.g.
\[[!table header="""
Name | Platform ||
| Windows | Mac | Linux
""" data="""
ikiwiki | ‧ | ✓ | ✓
"""]]
-- [[Jon]]
[[!tag wishlist patch]]
> This seems like weird overloading of the header parameter - it's
> table data, except when it isn't.
> > My first cut (now rebased out of existence I think) introduced a
> > new "headerblock" parameter, but trying to clearly document the
> > interaction of data/headerblock/header parameters was too awkward. -- [[Jon]]
> Perhaps
> something like this would be easier to use in practice?
> (and also more featureful :-) )
>
> \[[!table header="2 rows 1 column" data="""
> Name | Platform ||
> | Windows | Mac | Linux
> ikiwiki | no | yes | yes
> Starcraft | yes | yes | via Wine
> """]]
> > Thanks for your prompt feedback!
> >
> > This would probably be good, yes, and having mixed row/column headers is
> > definitely a nice-to-have. I don't relish the prospect of writing the parser
> > but I see you've made a stab already...
> >
> > One thing you'd lose, but it's debatable whether this is valuable, would be
> > to have the header defined in the directive, and the remaining table data
> > declared in an external CSV. -- [[Jon]]
> intended to be rendered like
>
> <table>
> <tr><th>Name</th><th colspan=2>Platform</th>
> <tr><th></th><th>Windows</th><th>Mac</th><th>Linux</th></tr>
> <tr><th>ikiwiki</th><td>no</td><td>yes</td><td>yes</td></tr>
> <tr><th>Starcraft</th><td>yes</td><td>yes</td><td>via Wine</td></tr>
> </table>
>
> (Deliberately switching to plain-text to make it more obvious
> what's a `<th>` and what's `<td>`.)
>
> Vague pseudocode for parsing `headers`
> (possibly even valid Perl, I'm not sure):
>
> my ($header_rows, $header_cols);
> while ($header =~ s/(\d*)\W*(\w+)//) {
> my $n = ($1 or 0);
> my $what = $2;
> if ($what =~ m/rows?/) {
> $header_rows = $n;
> }
> elif ($what =~ m/col(?:umn)?s?/) {
> $header_cols = $n;
> }
> }
>
> and it would even be fairly easy to extend to support
> `(first|last|)\W*(\d*)\W*(\w+)` later, e.g.
> `header="1 row, first 2 cols, last column"`.
>
> --[[smcv]]
> > To be clear I think your suggestion is a good one, but my hack has
> > addressed my immediate need so it's the one I'm deploying at $ork for the
> > time being. I'm unlikely to have time to implement this solution in the
> > near future. -- [[Jon]]
----
I'd quite like to revisit this if that's ok. I'm still carrying a fork of
table.pm locally to add this feature as I find it so useful. The main objection
you made back in 2014 seems to be overloading the header= parameter, and I agree
that this is not ideal. So I'm happy to resubmit this with an alternative parameter
name for the new purpose. But I balked at the idea of implementing something like
an NLP processor to define the header range. And I must stress how useful it is in
practise to separate out the header definition from the data: quite often I don't
want headers in my CSV files at all, for example, so I can perform rudimentary analysis
on them with command line tools without having to factor in a header line (how many
records? = `wc -l`; sorting on fields simply with `sort -k` etc.). Having them
separate means I can have machine-generated or manipulated CSV files of data and then
use ikiwiki to mark them up for human reading, but change or regenerate the data quickly
and easily underneath.
I'd appreciate your take on the above suggestions [[smcv]] before I roll my sleeves up.
Thanks! — [[Jon]] (2018-09-24)
|