[pmwiki-devel] hello! 2 issues.

Subhrajit Bhattacharya subhrajit at gmail.com
Fri Apr 2 15:25:40 CDT 2010


hello all,
I just joined this list and this is my very first message. I had lately been
working on a few PmWiki recipes (
http://www.pmwiki.org/wiki/Cookbook/TrueLatex ,
http://www.pmwiki.org/wiki/Cookbook/LiveEdit ), but haven't been in this
mailing list so far. But now I am in! :)

I had been working on the recipe called 'LiveEdit' (
http://www.pmwiki.org/wiki/Cookbook/LiveEdit) 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.


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').

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.

Relevance to LiveEdit: In the AutoDetect mode of LiveEdit I need to identify
the position of the potential blocks of wiki-text.


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.

Possible solution: Do not hard code $PageStartFmt and $PageEndFmt in
pmwiki.php, instead use a recursive definition. That is, use something like
   $PageStartFmt = array(&$HTMLStartFmt,"\n<div id='contents'>\n", clone
$PageStartFmt);
   $PageEndFmt = array(clone $PageEndFmt, '</div>',&$HTMLEndFmt);
instead of the present
   $PageStartFmt = array(&$HTMLStartFmt,"\n<div id='contents'>\n");
   $PageEndFmt = array('</div>',&$HTMLEndFmt);

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.


Thanks,
Subhrajit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20100402/35cb15f2/attachment.html>


More information about the pmwiki-devel mailing list