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 <[email protected]> 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 <[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
