[pmwiki-users] New {$$ } and {( )} markups [Was: Can any of the form recipes do this?]

Patrick R. Michaud pmichaud at pobox.com
Tue Apr 3 08:56:16 CDT 2007


On Tue, Apr 03, 2007 at 08:58:42AM -0400, The Editor wrote:
> 1) I'm not convinced there's much chance of conflict.  
> [...]
> Perhaps more importantly, as these are *ONLY* used in ZAP
> contexts (on form submission values) they in no way interfere with any
> other markup used elsewhere on a page. 

...but can you guarantee that other markups on a page that end up
with "{...}" in them won't interfere with ZAP?  What if I define a
{{foo}} markup, and {foo} means something in ZAP?

> 2) I'm not sure ZAP/ADL/FOX should use the same syntax as core--as
> that IS likely to produce conflict.  
> [...and then much later...]
> Also, I thought it was nice Fox, ADL, and ZAP all used the same
> template syntax basically, meanting they were interchangeable.  If
> Hans change Fox, it will just make things more confusing, not less.

I have trouble reconciling these statements -- if a lot of recipes
are using identical syntax, there's no overwhelming reason to keep
the syntax out of the core.

> At the very least, until more information is
> forthcoming about how these will work in PmWiki, I'm more inclined to
> wait and see whether ZAP might want to be able to handle the markups
> directly

No problem.  As I said in my followup message [2], I'm not at all
asserting that any existing recipes "absolutely must" change their
syntaxes -- only that I think it's a risky way to go, and that as
PmWiki looks at convergence with other markup languages we may find
that {...} has to be available for something else.  (Consider LaTeX.)

> 1)  I really hate the thought of breaking so many existing forms,
> documentation, snippets, etc., that would be involved with this
> change.

Welcome to my world.  Sometimes the way to avoid breaking things
in the future is to avoid steps that might paint us into a corner.
(Using {...} as a generalized markup has the potential to do that.)

> On the introduction of a new functional markup {( )}, I am a bit
> perturbed, as I've just completed a major rewrite of the ZAPmarkup
> module using this notation (based on Pm's encouragement) and reworked
> all the snippets and documentation at ZAPsite to use the new notation,
> only to discover now (days later) it about to be taken over by a new
> (identical) core syntax.  It's a good syntax, and it was Pm's idea,
> but I wish he hadn't encouraged me to use it!  :)

I didn't say that it's imminent, only that we might want to eventually
fold something like this into a core syntax.  But this is also a
case where we'd probably introduce {(...)} in a manner that doesn't
break ZAP (or at least not in a big way), so don't panic just yet.

It's also very possible that {(...)} would end up being a recipe
as opposed to a core markup.

> I note Hans version involves a colon while Pm's does not.  

My version might end up using a colon -- I'm still thinking
about it.  But at this point I'm thinking it likely won't.

> [...] Depending on how Pm
> sets up the core function (I'm assuming it will be extensible), I
> could rewrite the ZAPmarkup module to take advantage of any features
> he doesn't bring into core.

Yes, any markup I bring in would definitely be extensible.  The 
(:directive:) markup has been quite extensible, I don't see any
reason why {(...)} cannot also be extensible.

> But in the mean time, I'd really like some
> input on where to go with this--as I just deprecated the old {#
> markup} to the dogpile--so my users are now caught in a bit of a
> bind...  

Well, my original warning was against the single curly brace as
a closer.  I did suggest {(...)} as a potential replacement, but
I wasn't necessarily expecting ZAP to make a wholesale switch
so quickly, or without a bit more discussion about its internal
syntax.  

For example, ZAP's version of {(...)} appears to use the vertical
brace as argument separators, which seems very different to the
approach that most other PmWiki markups use, which is to use
whitespace to delimit arguments and key=value pairs.  PmWiki
even provides an excellent ParseArgs() function to do all of the
argument parsing, so I'm a bit surprised to see a syntax based
on vertical braces as separators.  It's definitely not as clear
to read -- I would have never guessed that "HomePage" in the
following means "exclude HomePage from the count".

    {(count Snippets|HomePage)}

Something like the following would be much clearer:

    {(count group=Snippets name=-HomePage)}

Similarly, instead of

    {(time Next Thursday|+9h|%m %d)}

it might be nice to have

    {(time "Next Thursday" fmt="%m %d")}

so that people aren't guessing as to what the arguments mean.  As
an example, I have absolutely no clue what the meaning of "+9h" is 
in the earlier version.

So, to get back to your original request ("input on where to go on
this"), I'd say that it's okay to continue with {(...)} for now.
For consistency with other markups I'd recommend moving to a more
ParseArgs-style syntax over the existing arg1|arg2|arg3 syntax,
but that's your option.

Or, if we really think it's worthwhile to standardize {(...)},
I propose that we go ahead and identify some standard functions
that everyone seems to want (time, date, substr, toupper, tolower, 
etc.) and I'll write a base recipe for it that can stand apart
from either ZAP or Fox.  Then ZAP and Fox can extend that as needed,
and we'll have much less opportunity for conflict with the {(...)}
markup in the future.

Pm



More information about the pmwiki-users mailing list