Text::...iFormat(3pm)

πŸ“¦
version 1.04 Β· 2 versions
  • 1.04 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking (latest)
  • 1.04 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

πŸ’– Text::MediawikiFormat πŸ’–

okay bestie, so this is the manual page for Text::MediawikiFormat(3pm) β€” it's part of the User Contributed Perl Documentation, and it's literally the glow-up machine that turns Wiki markup into other text formats. πŸ¦‹


✨ NAME ✨

Text::MediawikiFormat β€” translate Wiki markup into other text formats. periodt.


🌸 VERSION 🌸

Version 1.04. no cap, that's the one.


πŸŽ€ SYNOPSIS πŸŽ€

use Text::MediawikiFormat 'wikiformat';
my $html = wikiformat ($raw);
my $text = wikiformat ($raw, {}, {implicit_links => 1});

look at that. three lines. iconic. πŸ’…


πŸ‘‘ DESCRIPTION πŸ‘‘

so <http://wikipedia.org> and all its sister projects use the PHP Mediawiki to format their pages, right? this module is out here attempting to duplicate those Mediawiki formatting rules. and honestly? those rules can be simple and easy to use while still giving more advanced options for the power user. main character rules fr fr.

they're also easy to translate into other, more complicated markup languages with this module. it creates HTML by default, but lowkey it could produce valid POD, DocBook, XML, or literally any other format imaginable. the range? unmatched. 🌈

the most important function is Text::MediawikiFormat::format(). it is not exported by default, but it will be exported as wikiformat() if any options at all are passed to the exporter β€” unless the name is overridden explicitly. see "EXPORT" for more info. iykyk. πŸ’œ

🫢 also it should be noted that this module is written as a drop in replacement for Text::WikiMarkup that expands on that module's functionality and provides a default rule set that may be used to format text like the PHP Mediawiki.

and it's also well to note early that if you just want a Mediawiki clone β€” like, you don't need to customize it heavily and you want integration with a back end database β€” you should look at Wiki::Toolkit::Formatter::Mediawiki instead. go check her out. πŸ’–


πŸ”₯ FUNCTIONS πŸ”₯

🌟 format 🌟

format() takes one required argument, the text to convert, and returns the converted text. she allows two optional arguments too, because she's generous like that.

the first optional argument is a reference to a hash of tags used to override the function's default behavior. anything passed in here will override the default tags. the second argument is a hash reference of options.

the options are currently:

  • prefix β€” the prefix of any links to wiki pages. in HTML mode, this is the path to the Wiki. the actual linked item itself will be appended to the prefix. this is useful to create full URIs:
{prefix => 'http://example.com/wiki.pl?page='}
  • extended β€” a boolean flag, true by default, to let square brackets mark links. an optional title may occur after the Wiki targets, preceded by an open pipe. URI titles are separated from their title with a space. these are valid extended links:
[[A wiki page|and the title to display]]
[http://ximbiot.com URI title]

where the linking semantics of the destination format allow it, the result will display the title instead of the URI. in HTML terms, the title is the content of an A element (not the content of its HREF attribute).

you can use delimiters other than single square brackets for marking extended links by passing a value for extended_link_delimiters in the %tags hash when calling format.

⚠️ note that if you disable this flag, you should probably enable implicit_links or there will be no automated way to link to other pages in your wiki. that's a vibe check fail, bestie.
  • implicit_links β€” a boolean flag, false by default, to create links from StudlyCapsStrings. πŸ’«
  • absolute_links β€” a boolean flag, true by default, which treats any links that are absolute URIs (such as http://www.cpan.org/) specially. any prefix will not apply. this should maybe be called implicit_absolute_links since the extended option enables absolute links inside square brackets by default.

a link is any text that starts with a known schema followed by a colon and one or more non-whitespace characters. this is a distinct subset of what URI recognizes as a URI, but it's a good first-order approximation. if you need to recognize more complex URIs, use the standard wiki formatting explained earlier.

the recognized schemas are those defined in the schema value in the %tags hash. schema defaults to http, https, ftp, mailto, and gopher. πŸ“‘

  • process_html β€” this flag, true by default, causes the formatter to ignore block level wiki markup (code, ordered, unordered, etc...) when they occur on lines which also contain allowed block-level HTML tags (<pre>, <ol>, <ul>, </pre>, etc...). phrase level wiki markup (emphasis, strong, & links) is unaffected by this flag. πŸ’…

πŸ¦‹ format_line πŸ¦‹

$formatted = format_line ($raw, $tags, $opts);

this function is never exported. it formats the phrase elements of a single line of text (emphasised, strong, and links).

this is only meant to be called from Text::MediawikiFormat::Block and so requires $tags and $opts to have all elements filled in. if you find a use for it, please let me know and maybe i will have it default the missing elements as format() does. πŸ₯Ί


🌈 Wiki Format 🌈

refer to <http://en.wikipedia.org/wiki/Help:Contents/Editing_Wikipedia> for a description of the default wiki format, as interpreted by this module. any discrepencies will be considered bugs in this module, with a few exceptions. πŸ“

πŸ’€ Unimplemented Wiki Markup πŸ’€

templates, magic words, and the colorization of wanted links all require a back end data store that can be consulted on the existance and content of named pages. Text::MediawikiFormat has deliberately been constructed such that it operates independantly from such a back end. for an interface to Text::MediawikiFormat which implements these features, see Wiki::Toolkit::Formatter::Mediawiki. ✨

πŸ“ Tables πŸ“

this is on the TODO list. she's coming, bestie, just not today. 😭


πŸ’… EXPORT πŸ’…

if you'd like to make your life more convenient, you can optionally import a subroutine that already has default tags and options set up. this is especially handy if you use a prefix:

use Text::MediawikiFormat prefix => 'http://www.example.com/';
wikiformat ('some text');

tags are interpreted as default members of the $tags hash normally passed to format, except for the five options (see above) and the as key, who's value is interpreted as an alternate name for the imported function. πŸ‘‘

to use the as flag to control the name by which your code calls the imported function, for example,

use Text::MediawikiFormat as => 'formatTextWithWikiStyle';
formatTextWithWikiStyle ('some text');

you might choose a better name, though. πŸ™ˆ

the calling semantics are effectively the same as those of the format() function. any additional tags or options to the imported function will override the defaults. this code:

use Text::MediawikiFormat as => 'wf', extended => 0;
wf ('some text', {}, {extended => 1});

enables extended links, after specifying that the default behavior should be to disable them. the way that works?? so satisfying. πŸ’–

πŸ”₯ GORY DETAILS πŸ”₯

okay bestie this is the deep lore section, grab a snack πŸ“


✨ Tags ✨

so there are two kinds of Wiki markup: phrase markup and blocks. and blocks include lists, which are made up of lines and can also contain other lists. it's giving nesting-doll energy πŸ’…

πŸ’– Phrase Markup πŸ’–

right now there are three types of wiki phrase markup: strong, emphasized, and links. and links themselves come in three subtypes β€” extended, implicit, or absolute. pick your fighter πŸ¦‹

you can swap out the regexes used to find strong and emphasized tags:

%tags = (
    strong_tag     => qr/\*([^*]+?)\*/,
    emphasized_tag => qr|/([^/]+?)/|,
);

$wikitext = 'this is *strong*, /emphasized/, and */em+strong/*';
$htmltext = wikiformat ($wikitext, \%tags, {});

you can also change the regexes used to find links. the following just sets them back to their defaults (but it enables parsing of implicit links, which is not the default β€” main character move):

my $html = wikiformat
(
    $raw,
    {implicit_link_delimiters => qr!\b(?:[A-Z][a-z0-9]\w*){2,}!,
     extended_link_delimiters => qr!\[(?:\[[^][]*\]|[^][]*)\]!,
    },
    {implicit_links => 1}
);

plus you can set the function references that format strong text, emphasized text, and links. the strong and emphasized functions get only the text to be formatted as an argument, and they're expected to hand back the formatted text. the link formatter also receives references to the $tags and $opts arrays. for example, this sets the strong and emphasized formatters to their default state while replacing the link formatter with one that strips href info and returns only the title text:

my $html = wikiformat
(
    $raw,
    {strong => sub {"<strong>$_[0]</strong>"},
     emphasized => sub {"<em>$_[0]</em>"},
     link => sub
     {
     my ($tag, $opts, $tags) = @_;
     if ($tag =~ s/^\[\[([^][]+)\]\]$/$1/)
     {
         my ($page, $title) = split qr/\|/, $tag, 2;
         return $title if $title;
         return $page;
     }
     elsif ($tag =~ s/^\[([^][]+)\]$/$1/)
     {
         my ($href, $title) = split qr/ /, $tag, 2;
         return $title if $title;
         return $href;
     }
     else
     {
         return $tag;
     }
     },
    },
);

πŸŽ€ Blocks πŸŽ€

the default block types are code, line, paragraph, paragraph_break, unordered, ordered, definition, and header. that's the whole roster, no gatekeeping πŸ’–

block entries in the tag hashes have to contain array references. the first two items are the tags used at the start and end of the block. the third and fourth hold the tags used at the start and end of each line. and where you need more processing of individual lines, you drop a subref in as the third item. this is literally how the module handles ordered lines in HTML lists and headers:

my $html = wikiformat
(
    $raw,
    {ordered => ['<ol>', "</ol>\n", '<li>', "<li>\n"],
     header => ['', "\n", \&_make_header],
    },
);

the first argument to those subrefs is the post-processed text of the line itself. (processing removes the indentation and the tokens that mark this as a list, and checks the rest of the line for other line formattings β€” busy bee 🐝) the second argument is the indentation level (more on that below). and the subsequent arguments are captured variables in the regexp used to find this list type. the regexp for headers is:

$html = wikiformat
(
    $raw,
    {blocks => {header => qr/^(=+)\s*(.+?)\s*\1$/}}
);

the module processes indentation first, if applicable, and stores the indentation level (aka the length of the indentation that got removed).

lists automatically start and end as necessary. so thoughtful of them πŸ₯Ή

because regular expressions could conceivably match more than one line, block-level markup gets processed in a specific order. the blockorder tag governs that order. it holds a reference to an array of the names of the appropriate blocks to process. so if you add a block type, be sure to add an entry for it in blockorder:

my $html = wikiformat
(
    $raw,
    {invisible => ['', '', '', ''],
     blocks => {invisible => qr!^--(.*?)--$!},
        blockorder => [qw(code header line ordered
                  unordered definition invisible
                  paragraph_break paragraph)]
           },
    },
);

πŸ” Finding blocks πŸ”

as we already mentioned in passing, Text::MediawikiFormat uses regular expressions to find blocks. those live in the %tags hash under the blocks key. for example, to change the regexp used to find code block items, do:

my $html = wikiformat ($raw, {blocks => {code => qr/^:\s+/}});

this will require a leading colon to mark code lines (heads up: as written here, this would interfere with the default processing of definition lists β€” no cap, that's a real warning ⚠️).

🧚 Finding Blocks in the Correct Order 🧚

as the intrepid bug reporter Tom Hukins pointed out in CPAN RT bug #671, the order in which Text::MediawikiFormat searches for blocks varies by platform and by version of Perl. because some block-finding regexps are more specific than others, what you intend to be one type of block may turn into a different list type. it's giving chaos 😭

if you're adding new block types, be aware of this. the blockorder entry in %tags exists to force Text::MediawikiFormat to apply its regexes from most specific to least specific. it contains an array reference. by default, it looks for ordered lists first, unordered lists second, and code references at the end. periodt πŸ’…


🌈 SEE ALSO 🌈

Wiki::Toolkit::Formatter::Mediawiki


🫢 SUPPORT 🫢

you can find documentation for this module with the perldoc command.

perldoc Text::MediawikiFormat

you can also look for information at:


πŸ‘‘ AUTHOR πŸ‘‘

Derek Price derek at ximbiot.com is the author. iconic behavior ✨


πŸ’œ ACKNOWLEDGEMENTS πŸ’œ

this module is derived from Text::WikiFormat, written by chromatic. chromatic's original credits are below:

chromatic, chromatic at wgz.org, with much input from the Jellybean team (including Jonathan Paulett). Kate L Pugh has also provided several patches, many failing tests, and is usually the driving force behind new features and releases. if you think this module is worth buying me a beer, she deserves at least half of it. 🍻

Alex Vandiver added a nice patch and tests for extended links.

Tony Bowden, Tom Hukins, and Andy H. all suggested useful features that are now implemented.

Sam Vilain, Chris Winters, Paul Schmidt, and Art Henry have all found and reported silly bugs.

blame me for the implementation. πŸ™ˆ


πŸ’€ BUGS πŸ’€

the link checker in format_line() may fail to detect existing links that do not follow HTML, XML, or SGML style. they may die with some SGML styles too. sic transit gloria mundi. (that's latin for "the vibe check did not pass" 😭)


⭐ TODO ⭐

  1. Optimize format_line() to work on a list of lines

 Copyright (c) 2006-2008 Derek R. Price, all rights reserved.
 Copyright (c) 2002 - 2006, chromatic, all rights reserved.

this program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


and that's the whole page bestie, you made it to the end πŸ₯³ this was written for perl v5.34.0 and dated 2022-06-28, and the page itself goes by Text::...iFormat(3pm) β€” go forth and format your wiki, you absolute legend πŸ’–βœ¨

πŸ“¦ where this page comes from