[pmwiki-users] Re: Modified (:markup:)

Joachim Durchholz jo at durchholz.org
Mon Mar 21 13:29:03 CST 2005


Patrick R. Michaud wrote:

> On Mon, Mar 21, 2005 at 06:23:38PM +0100, Joachim Durchholz wrote:
> 
>>  \[ (=+) ( \] | (.*?) \1 \] )
> 
> I thought of this previously, the bad part being that it's then
> impossible to escape anything that begins with a closing bracket,
> which just seems wrong.  I.e., in the current implementation I can do
> 
>    [=]]=]
> 
> but this wouldn't work if we disallow bracket as an initial character.
> Yes, I can come up with cases where someone might want this -- e.g.,
> if they need to place an escaped closing bracket inside of link text.

Hmm... I don't think that it's possible to avoid this problem entirely. 
After all, we already can't escape =] itself.

The interesting question being, of course, whether that's a real 
problem. I tend to insert a blank whenever there's any doubt about the 
actual parse, so I would have written the above example as [= ]] =] anyway.

Hmm... OTOH the whole point was to have a block escape that will always 
work. The whole [===... idea goes only half of the way.

Back to the drawing board then... find a markup for "this shouldn't be 
interpreted by PmWiki", *and* that can be escaped if needed.

The only reliable way to do this that I know is like the string 
delimiters in C or Pascal (the contents of a string must not be 
subjected to the usual parsing rules of the language, so the situation 
is similar).

C uses a quote character, and a separate "escape" character "to quote 
the quote".
Pascal uses a quote character, and doubles it where it should be part of 
the escaped text.

Both conventions can be very, very confusing if multiple quoting comes 
into play. I don't think that's an issue in PmWiki (is it really?)

I have used both conventions, and found the Pascal one even more 
confusing than the C one. (Try grokking """" if you like...)

I don't know of any way to reliably do this kind of escaping with 
multi-character delimiters. There's always a potential for ambiguity at 
the end of the

Regards,
Jo



More information about the pmwiki-users mailing list