[pmwiki-devel] disabling and modifying markup for specific recipe output

[Dominique Faure]

On Thu, Aug 27, 2009 at 19:27, Hans<design5 at softflow.co.uk> wrote:
>
> I like to summarise my findings:
>
> At present it is not possible to add new markup or disable markup
> from within  a function called by other markup (for instance via a
> markup expression or directive).
> If MarkuptoHTML() is called function BuildMarkupRules() fails to
> update the markup rules.
>
> Now I am not sure if this could be regarded as a bug. It is certainly
> fixable as I outlined previously, with little effort.
>
> If it gets fixed, it opens the possibilities of adding and disabling
> markup and changing the MarkupTable from within functions.
>
> But I also realised that disabling a markup can have consequences
> beyond the desired output, for instance changing parts of the page
> rendering which is processed later (I seen it in the SideBar).
> So one would also need a means of re-enabling the markup after
> the call to MarkupToHTML(). But function DisableMarkup() changes the
> $MarkupTable in a way that will not allow easy re-enabling, and only
> leaves the option of newly defining the disabled markup.
>
> In other words: $MarkupTable and the functions dealing with it are not
> set up to allow switching a markup on and off in  a simple way, and
> if one wanted this feature of modifying markup for specific recipe
> output, then functions need possibly be able to save markup patterns
> for easy re-enabling etc.
>
> I don't see there would be much interest in this, but I still like to
> ask to make the fixes to function BuildMarkupRules(), so
> DisableMarkup() and Markup() functions can be called from functions.
>
>
> Hans
>
>
> _______________________________________________
> pmwiki-devel mailing list
> pmwiki-devel at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
>

Hi,

For now, and AFAI understood the code:

The two functions Markup(...) and DisableMarkup(...) are responsible
to register/unregister the markup rules in a (kind of) table, ie.
$MarkupTable:

The MarkupToHTML(...) function uses the BuildMarkupRules() function to
generate an ordered list of markup rules ($MarkupRules) from the
markup table definitions, then apply them on the page text in order to
translate it to HTML.

The $MarkupRules is only build if it hasn't been previously set, which
should occurs as soon as the Markup(...) and DisableMarkup(...)
functions has been called, cf. the unset($MarkupRules); instruction in
these two functions.

So, I first see a bug in DisableMarkup(), where the $MarkupRules isn't
declared as global, but according to the unset page in the php manual:

"If a globalized variable is unset() inside of a function, only the
local variable is destroyed. The variable in the calling environment
will retain the same value as before unset() was called."

This mean that the two functions Markup(...) and DisableMarkup(...) should use:

unset($GLOBALS['MarkupRules']);

to have it taken in account. BTW, the $MarkupRules wouldn't need to be
declared global there anymore.

-- 
Dominique

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en début de message est-il si effroyable?