[pmwiki-users] On the order of Markup

Peter Kay pkay42 at gmail.com
Wed May 3 12:19:00 CDT 2017

One other problem I recently stumbled on is that the MarkupRules only
allow one instance of a given pattern.

So for example if you want to process '/XXX/' twice (for whatever
reason), you can't - only one copy goes in.  I'd rather build the
rules using the markup name, so as long as the names are different,
they'll both run.


On Wed, May 3, 2017 at 1:17 PM, Peter Kay <pkay42 at gmail.com> wrote:
> The current tree structure would work great, except for the fact that
> all markup that is defined as "<X" gets lumped together (and seems to
> happen in alphabetical order?).
> I think the approach I would take is that the tree structure would
> follow the same ordering, so if you have markups:
> 'A', '<X'
> 'F', '<X'
> 'M', <X'
> 'D', '<F'
> 'Z', '>X'
> then I would like the tree structure to look like:
> X has 3 "before" children, A, F, M and one "after" child, Z
> F would have one "before" child, D
> Then building $MarkupRules would start with X, traverse all "before"
> children, add them to the list recursively etc.  So build the list "A"
> => "A" (F) => "A", (D) (F) => "A", "D", (F) => "A", "D", "F", etc.
> The order the "before" children of X have would be the same as
> currently.
> Currently, if we add 'E', '<M', we will have MarkupRules DE AFM Z,
> which is confusing because A and F are between E and M.  I propose to
> write BuildMarkupRules to return ADFEMXZ.
> --Peter
> On Tue, Mar 28, 2017 at 12:32 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>> On Thu, Mar 23, 2017 at 11:21:06AM -0400, Peter Kay wrote:
>>> textvar:       <split           B>><
>>> nl0              <split           B>><
>>> Sidebar          <split           B>><
>>> input+sp         <split           B>><
>>> nl1              >nl0             B>><>
>>> [...]
>>> I am wondering:
>>> 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".
>> Technically speaking, PmWiki *is* using a tree structure for ordering --
>> it's just not a binary tree.  The <'s and >'s are specifying ordering,
>> and it's always possible to insert nodes before or after an existing one.
>> The problem with a strictly binary tree structure (as described with
>> "each node having 'before' and 'after' branches") is that it's not
>> precisely clear what to do when you need to insert something "before" a node
>> that already has a "before" branch.
>> For example, if we have a node 'B' that already has 'A' before and
>> 'C' after, and we have a rule that needs to go before 'B', it's not
>> entirely correct to simply assume that it should go after 'A'...
>> especially if "A" was supplied by a recipe that also assumes it
>> will be happening immediately before "B".  And PmWiki can't know
>> the necessary ordering in advance, since these are coming from
>> recipes, and I didn't want the order in which recipes are included
>> to be the driving factor of markup rule order.
>> So, the approach PmWiki takes is to enable recipes to specify
>> whatever level of detail is necessary for ordering.  If you specify
>> "<split", you're guaranteed that your rule will occur before the split
>> rule, along with all of the other rules that specified "<split".
>> If the ordering of two of those rules ends up being important
>> (as happened in your case), then the way to resolve it is to specify
>> the ordering of one of the rules in terms of the other... which is
>> exactly the solution you came up with.
>> Pm

More information about the pmwiki-users mailing list