[pmwiki-devel] hello! 2 issues.

[Subhrajit Bhattacharya]

Thanks Petko for the insights. I understand your points.

Regarding the solution for the issue 1 that you have suggested, actually the
issue was not with just identifying the positions, but with relating the
positions with corresponding replacements made by the markups. The positions
can anyhow be captured independently in the $page['text'] variable in the
recipe's code. But that does not give a way to create a markup replacenent
that is a function of the position. Moreover, I had tried something on the
line of what you said, and it seems some of the pre-processors actually
change the content of the wiki-text even before the '_begin' or even
'<_begin' stage (e.g. I was getting <:vspace> in place of "\n\n" even at the
'<_begin' level). I guess it's natural to expect that.

I will try out your suggestion for the issue 2 in the next release of
LiveEdit. I am planning to work on it in a few months. If you wanna try out
LiveEdit and let me know your suggestions in the mean time that will be
absolutely great! :-)

Thanks,
Subhrajit.


On Sun, Apr 4, 2010 at 7:54 PM, Petko Yotov <5ko at 5ko.fr> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20100405/a403f2e3/attachment.html>