[pmwiki-users] On the order of Markup
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:
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.
More information about the pmwiki-users