[pmwiki-users] On the order of Markup

[Petko Yotov]

On 2017-03-23 16:21, Peter Kay wrote:
> It seemed my pattern ('/^\(:sidebar ...') wasn't matching for some
> reason.  After further digging (I'm a curious person) I discovered
> that the default $GroupHeaderFmt='(:include {$Group}.GroupHeader
...
> that (:nl:) was showing up at the very beginning of the page before my
> markup ran, so
...
> my markup was passing over
> (:nl:)(:sidebar Title etc :)
> My markup pattern no longer finds (:sidebar ... because it is no
> longer at the beginning of a line.

I agree sometimes the markup configuration, and regular expressions are 
a pain.

I sometimes ask myself if I absolutely require for a markup to be on the 
very first line, or start as a very first character on the line.

Also, sometimes I find that I've forgotten the modifiers "/s" (dot may 
be a new line) or "/m" (caret may be a new line).

> (As an aside, this was NOT happening when the first character of the
> page was not a parenthesis - if my markup was Xsidebar ... then it
> worked just fine.  I'm still not quite sure why this was happening)

Yes, this is unusual, no reason this should have happened.


> Is there any particular benefit to this non-intuitive approach to
> ordering markup?  A tree structure strikes me as the more intuitive
> way to order things, with each node having "before" and "after"
> branches.  Then MarkupToHTML can traverse the tree and "nl1" will
> happen immediately after "nl0".

I wasn't around when this design choice was made, however, the markup 
engine must allow you to specify new markups before the default markups 
are defined (recipe.php is loaded before stdmarkup.php) or after 
($PostConfig), to disable some default markups, or even stdmarkup.php, 
and to restart the processing, eg. after an include or a 
pagelist+template. The current system, indeed rather complex, does that.

> If there's no reason not to, if an enterprising author were to write
> the necessary changes, would we add them to pmwiki?

Yes, if there is a way that all current core markups, recipes and local 
customizations are not affected.

Or, if you only require a hook or a switch for a recipe, it could be 
added more easily.

For example, we could easily add a variable $MarkupToHTMLFunction which 
contains a custom function name, and that function will be called to 
perform all markup processing. It would either use the core arrays 
$MarkupFrame and $MarkupRules, or its own variables.

(The same way one can redefine $AsSpacedFunction or $StrFoldFunction or 
$MakePageNameFunction and others.)

If this is requested I can add it for the next version before the end of 
the month.

> If any other cookbook authors have written recipes with multiline
> markup and haven't tested it on the first line of a page, my original
> problem might not be isolated.

The core markup "!vspace" is both start-of-line and multiline, and it 
appears to work. It removes one vertical space after a section heading, 
even when the heading is on the first line of the page.

> Adding a newline to the end of GroupHeaderFmt would also solve this.
> 
> Likewise, adding a newline to the beginning of GroupFooterFmt might be 
> wise.

The (:nl:) markup does exactly that, it adds a new line if one is not 
already there. Make sure your rules are processed after it.

Petko