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