[pmwiki-users] {(...)} markup recipe available

The Editor editor at fast.st
Thu Apr 12 19:39:38 CDT 2007


On 4/12/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Thu, Apr 12, 2007 at 05:47:21PM -0400, The Editor wrote:
> > BTW, it may be a small thing, but I really l wish you had gone with
> > time not ftime.  Is there a reason you made that choice Pm?
>
> The biggest reason was to leave the {(time ...)} expression available
> for other purposes if we came up with any.  Some people had been
> talking about using {(time)} to return the current time as a Unix
> time value (i.e., the equivalent of {(ftime %s)} ).

Hmmm.  That's what I assumed the default would be.  In my now
deprecated version of this {(time)} did return a timestamp.  I can
live with having to add the %s but would still rather use time instead
of ftime. You're probably right the default should be formatted (for
the same reasons I advocate time) but I would have personally
preferred the timestamp for default. I can reset the default of
course...

> There's also potential confusion that people might not recognize
> that {(time ...)} could also be used to format dates -- they
> might think it's restricted to time-of-day only.

ftime doesn't exactly clarify that confusion much.  In fact knowing
time in php can be used any way you want to me suggests time would be
better option.  I'd never guess to try ftime.  I might think time.

> Lastly, Dominque had used "ftime" in his version of expressions,
> and I thought it was a nice compromise between "time" and "strftime".

It may be a nice compromise but doesn't really make either more clear.
 I would encourage us to use the very simplist syntax for the most
core functions, and this function is a jewel Pm.

> But I'd be perfectly happy to just make {(time ...)} the core
> standard instead of {(ftime ...)}, if people are in general
> agreement about this.

One vote plus!  I think it is a better in consideration of new PmWiki
users who may not even know what ftime is.  Anything we can do to get
people thinking PmWiki is less hard to learn is good.

Thanks again for your work Pm.  Always superb.

Cheers,
Dan



More information about the pmwiki-users mailing list