[pmwiki-users] On the order of Markup

[Peter Kay]

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.

--Peter


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