hello all,<br>I just joined this list and this is my very first message. I had lately been working on a few PmWiki recipes ( <a href="http://www.pmwiki.org/wiki/Cookbook/TrueLatex">http://www.pmwiki.org/wiki/Cookbook/TrueLatex</a> , <a href="http://www.pmwiki.org/wiki/Cookbook/LiveEdit">http://www.pmwiki.org/wiki/Cookbook/LiveEdit</a> ), but haven't been in this mailing list so far. But now I am in! :)<br>
<br>I had been working on the recipe called 'LiveEdit' (<a href="http://www.pmwiki.org/wiki/Cookbook/LiveEdit">http://www.pmwiki.org/wiki/Cookbook/LiveEdit</a>) and have recently released the v2.0. While working on it I faced couple of issues, for which I had to devise workarounds. As it will be a long story to describe here how those issues are important or relevant for LiveEdit, I will just state the issues and propose solution for including in future release of PmWiki. I am not sure if there already exist ways to deal with these. If so, please advise.<br>
<br><br>Issue 1: There is no way that the replacement string passed to the Markup() function (its 4th argument) can catch the position of the markup matches in the wiki-text (like the $match returned by PHP preg_match function), besides catching the matches themselves ('\$n').<br>
<br>Possible solution: I understand that the markup table is used to parse the markups in a certain sequence, and hence the position of a markup within a partially parsed wiki-text will be quite useless. The solution may be that the MarkupToHTML() function will use preg_match() (with PREG_OFFSET_CAPTURE turned on) instead of preg_replace(), and hold the actual replacements for the very end. Once all the positions of the markups are captured and replacements populated, the replacements are done in one go at the end. That way not only we'll be replacing the markups, but also capyuring their respective positions in the wiki-text. I have resorted to something of that sort in the LiveEdit code if you would like to take a look into it to see what I mean.<br>
<br>Relevance to LiveEdit: In the AutoDetect mode of LiveEdit I need to identify the position of the potential blocks of wiki-text.<br><br><br>Issue 2: The way presently $HandleBrowseFmt, $PageStartFmt and $PageEndFmt are defined, it is difficult for multiple different recipes to include items before and after the '$PageText' in a reliable manner. For example, recipes1.php can do something like SDV($HandleBrowseFmt, array(&$PageStartFmt, &$PageRedirectFmt, $Recipes1FixedMenu, '$PageText', &$PageEndFmt));. But then, something similar in recipes2.php (included after recipes1.php) will have no effect. Whereas, something like inserting $Recipes2FixedFooter in the $HandleBrowseFmt array has the disadvantage that recipes2.php doesn't know where to insert, and then $HandleBrowseFmt may not even get set properly down the stream. Moreover setting $PageStartFmt or $PageEndFmt have no effect since they are hard-coded in pmwiki.php.<br>
<br>Possible solution: Do not hard code $PageStartFmt and $PageEndFmt in pmwiki.php, instead use a recursive definition. That is, use something like<br> $PageStartFmt = array(&$HTMLStartFmt,"\n<div id='contents'>\n", clone $PageStartFmt);<br>
$PageEndFmt = array(clone $PageEndFmt, '</div>',&$HTMLEndFmt);<br>instead of the present<br> $PageStartFmt = array(&$HTMLStartFmt,"\n<div id='contents'>\n");<br> $PageEndFmt = array('</div>',&$HTMLEndFmt);<br>
<br>Relevance to LiveEdit: The LiveEdit menu is a position:fixed div block in the page that needs to be introduced reliably somewhere in the page's HTML.<br><br><br>Thanks,<br>Subhrajit.<br><br>