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
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
