[pmwiki-users] Different Markup definitions for a section?

[Dominique Faure]

On 4/24/06, Joachim Durchholz <jo at durchholz.org> wrote:
> Stirling Westrup schrieb:
> >
> > That won't work. I want to KEEP the existing markup when its outside the
> > special section, and change it inside. Thus:
> >
> > ! This is a normal heading
> > (:special-section:)
> > ! This is a completely different markup!
> > (:end-special-section:)
> > ! This is again the normal heading markup
> >
> > So, I need to have the entire set of Markups change while handling
> > special sections. Thats what I don't know how to do.
>
> If the markup is of your own devising, you can set a flag in the handler
> for (:special-section:), and have the ! markup check for that flag and
> return the unchanged text if the flag is set.

First design approach (see below)

> Alternatively, (:special-section:) could eliminate the given markups
> from the markup table, and (:end-special-section:) could reintroduce them.
> This would require some moderate PHP coding.
> Note that adding or removing a markup rule invalidates the rule table,
> so PmWiki will automatically recompute rule ordering the next time it is
> doing markup substitution; if there are many special sections on a
> table, this might take too much time.

Second design approach (see further)

> A third approach might be wrapping the markup entries. For each markup
> that must be disabled inside special sections,
> * save the replacement data for that markup,
> * place your wrapper code as replacement data.
> The wrapper code would be something that checks the special-section
> flag, and if it's set, it would return the original string, and if it's
> not set, it would return the replacement string. (There are
> ramifications if the original pattern uses the /e flag. It's all
> feasible, but it does require serious PHP and regex knowledge.)

Well, IMHO we're hitting here the same problem as in trying to handle
both variables and conditional statements into page markup.
 Taking a more global perpective, the currrent PmWiki markup handling
implementation is roughly to apply an ordered list of regular
expression-based transformations on the page text.

Most of these transformations may be structurally considered as
trivial (heading, bold, italic, links,...) since they may apply
everywhere in the text flow. For now, only few rules are a bit more
tricky as being more context-dependent (aka. line leading whitespaces
or text block divisions) but are gracefully handled following
principles suggested by the first design approach above, IOW let the
markup rule handle the context itself.
This lead to a complex and error-prone rule design (see the recent
space-leaded list item bug/feature described at
http://www.pmwiki.org/wiki/PITS/00722).

The second design approach is to be considered as an utmost extension
of the previous case (see
http://www.pmwiki.org/wiki/Cookbook/Variables for a living sample).

In fact, processing text with markup is to be considered as a
programming language as PHP could be (even if it is simpler).
Therefore, if the current rule system is quite powerful at handling
the syntaxic aspects of this markup language, the need is here to
improve the grammatical structure it has, providing *real* block
statements, and this couldn't be done without a non trivial
enhancement of the PmWiki markup core itself.

> If you want to take any of these routes, I can look up what variables
> and functions to use, and what pitfalls to avoid.

Your help is welcome!

Regards,
Dom

--
The difference between theory and practice in theory is much less
than the difference between theory and practice in practice.
 — Randal L. Schwartz