Russ Allbery <rra@stanford.edu> wrote: |Steffen "Daode" Nurpmeso <sdaoden@gmail.com> writes: |> Russ Allbery <rra@stanford.edu> wrote: | |>|If you do decide to use POD, you may want to pick a different letter than |>|I, since I<> is already a POD formatting code (for italics). D<> is safe |>|to use; there's no existing formatting code. | |> Well, that was just what came to my mind on saturday. |> Maybe U<> (for URL)? It seems unused. | |Yup, that would work. (Updated it already.) |> I also can hardly imagine that spreading formatting tags will be |> accepted by the actual tz maintainer(s), since otherwise they |> might have done it 15 years ago. | |True. :) | |> I think the script can easily get extended by another mode which simply |> takes an encoding name and reads text from STDIN/file, converting to tz |> database-style comment output along the way; i.e., HTML entities. It |> would have to decode HTML entities to E<>, which should work, then? |> Shouldn't be that hard either. | |Yup, that would also work and wouldn't be too difficult, since E<> takes |the same values as HTML entities. | |> ..Well i think for L<> to work the way you show it above the POD parser |> must be adjusted; or we need to use special tags and make POD treat them |> as links. | |You mean the L<anchor|http://www.example.com/> form? No, that's just Weeeeeelll ... this indeed works for newer perl(1)s! I first got stuck since the laptop hardware driving OS has 5.8.9 and 5.10.0 installed, and those do not support L<TEXT|scheme:>: But note that there is no corresponding "L<text|scheme:...>" syntax, for various reasons. (But the VM-based loved one with 5.16.1 got it right.) |standard POD; any POD parser will handle that out of the box. Or do you |mean not emitting the contents of U<> and D<>? that would indeed require |some tweaks, but not very difficult ones. | |> I haven't yet used POD any more sophisticated than this: | |> use Pod::Text; |> my $parser = Pod::Text->new(loose => 1, indent => 0, width => 72); |> $parser->parse_from_file($0, '-'); | |> and of course normal module documentation, so some hints how to do |> the required task would be appreciated. | |Basically, you tell Pod::Simple that you accept some additional formatting |codes with: | | $parser->accept_codes(qw(D U)); .. and this one is unknown to Pod::Simple there, too. |and then add new cmd_d and cmd_u subs that do whatever they should do with |the contents. I can explain more if anyone is interested in going this |direction. Well it sounds pretty much straightforward and tofu-y for a new perl(1), but it seems 5.14 is required to get access for both features, and 5.12 for using L<text|scheme:> alone. Thus i think htwork.pl would have to work as an intermediate filter that converts from a(n almost unmodified) tz database file into an array of lines that could then be fed into a POD parser (via ->parse_lines()), and from then on the options are pretty versatile. I.e., the script, if converted to <|> (| is ALT-7 on a german Mac keyboard btw. :/), must be prepared to convert this to something perl(1) version dependent. I really don't think it can assume a v5.14. But hey - thanks for these pointers! |> It of course all stands and falls with wether these adjustments |> will be acceptable for the tz database as such. |> I'm not planning to fork the project. | |Indeed. My offer still holds. |-- |Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> --steffen