[pmwiki-devel] hello! 2 issues.

[Petko Yotov]

On Friday 02 April 2010 22:25:40, Subhrajit Bhattacharya wrote :
> 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! :)

Hello and welcome! Thanks a lot for your recipes -- LiveEdit looks impressive 
even if I haven't had the chance to look closer into it. :-)

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

I'm not sure if this would be at all possible. There are constantly needs to 
re-process something which some markup has returned. For example, any use of 
including other pages, group headers/footers, including sections, using 
pagelists, templates or even a search, needs to get some section from some 
page, and re-send it through the full set of markup rules. There are recipes 
which return not HTML but wiki markup, which will be either processed later, 
or again, will be sent through all markup rules.

For this reason, the original positions of the matches in the original page 
text doesn't mean much. And because too many things depend on the current 
implementation, we need to be very careful if we want to change it.

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

You could probably use a markup rule at the very beginning of the processing, 
which would store the break positions of the sections.

  Markup('liveeditsavepos', '_begin', '/^.*$/s', "MySavePosFunc(PSS('$0'))");
  function MySavePosFunc($text) {
    static $cnt=0; # do this only once
    if($cnt) return $text;
    $cnt++;
    // do your preg_match() here, store it in a global var
   return  $text;
  }

There could be better ways to do it, of which I haven't thought. 

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

Recipes could use array_search() and array_slice() to insert an entry in 
$HandleBrowseFmt, if it is already defined, or define it if it isn't.

>  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

They are not hardcoded, they are defined before config.php is included, and 
before recipes are included. They can be replaced by the user or by a recipe.

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

There are ways to add HTML to the page. One of them is to use the Markup() 
function to add something to the page text at the beginning or at the end of 
the processing (use the Keep() function for the markup engine to not process 
your content). Another could be, as your recipe uses JavaScript, to insert the 
new div in the DOM of the finished page.

Thanks,
Petko