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

The Editor editor at fast.st
Tue Apr 3 15:06:44 CDT 2007


> > ZAP would not mess up any such markup, though such a markup might mess
> > with a ZAP form.  But the problem then would be that that is bad
> > markup? Not really with ZAP.  Right?
>
> That's not how I would look at it.  To recipes and admins should have
> great freedom to define "uncommon" sequences such as {{...}},
> {{{...}}}, [{...}],  '{...}', /{...}/, etc. as markup.  Unfortunately,
> ZAP seems to be saying that things fitting the pattern {...}
> (which includes all of the markups I just listed) may be
> a ZAP field substitution.  IOW, ZAP's single-curly syntax is
> precluding the future use of a lot of potential markup sequences.
>
> Just to prove that this isn't entirely theoretical, the
> CREOLE markup specification says that {{{...}}} is used for
> inlined monospace text.  ZAP's definition would seem to prevent
> some words from being able to appear within {{{...}}},
> because the inner curlies could be interpreted in some
> situations as ZAP field substitutions.  If someone asks me
> which of {{{...}}} or {...} causes the problem, I definitely
> point at the {...} markup, because there are _many_ more places
> where {...} might appear that isn't intended to be a
> field substitution (including normal text!), but very few
> places that {{{...}}} is likely to cause a conflict.

Well maybe.  I doubt anyone would put {{{ }}} in a form field value,
but I guess it is possible.  And it might just have one word matching
a form field.  Big ifs...  But I see your point that would be ZAP's
responsibility as having carved out a more common markup.

As it's not an urgent issue, I'll not rush into this as quick as Hans.
 I'm also thinking field replacements (substitutions) and template
insertions should probably use different markups. Just to avoid
potential conflicts...  Do you have a better suggestion?   {= =} is
easy enough to type...

> > Though it's not all documented, there are some nice features in ZAP's
> > {(time)} function already.
>
> Could you summarize them quickly for me?

I'm willing to use different syntax--I just don't want to lose functionality:

count (group): normal pages, easily exclude extra page names or list all

thread (group): highest numbered page in that group + 1.  Default
starting point.

captcha: random number, number repeated in all later instances of
captcha on page

time: takes timestamp, or runs strtotime on first parameter, can +/-
seconds, minutes, hours, days, weeks (optionally), and then format
results using strftime(optionally).

time: alternately, takes a number like 03 or 3 combined with w or m to
return Tuesday, or March based on a configurable string.  Useful with
Hg for page names like 2007-03-15 (ie using {$n2}).

math: basic math processing.

list: (maybe a ZAP thing, but) it converts CSV lists into nicely
formatted output.  ZAP does a lot of nice CSV list handling with
arrays.  This adds more power to it.

source: returns source code from a page or a section of a page
(identified by an anchor). Specially formatted to work with textareas
to allow full editing of PmWiki pages directly within ZAP. (another
ZAP thing perhaps).

attr: returns attr values for an Admin. Makes an attr table a piece of cake.

php list:  executes any of the php commands in a configurable list...

directives list: probably a ZAP thing, allows you to store any listed
directives as a hidden text variable and execute when the variable is
retrieved.

Session vars: used for logging info.

Hope this helps,

Cheers
Dan



More information about the pmwiki-users mailing list