[pmwiki-users] On the order of Markup

Peter Kay pkay42 at gmail.com
Wed May 3 12:17:41 CDT 2017

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, 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.


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