[pmwiki-users] Re: New feature proposal - need help with markup selection

Joachim Durchholz jo at durchholz.org
Wed Mar 16 15:56:40 CST 2005


Patrick R. Michaud wrote:
> On Wed, 16 Mar 2005, Joachim Durchholz wrote:
> 
>>I propose two extensions with a very useful synergy: substitutions, and 
>>repeat groups.
>>[...long description...]
> 
> This all looks like one form or another of macro capability; i.e., giving
> authors the ability to define macros.  It's been discussed in the past,
> and I've generally decided against it (for the core) as being a little
> too far outside the PmWikiPhilosophy and in conflict with the needs
> of new authors (described in PmWiki.Audiences).  Also, I think that
> site-specific custom markups are a superior solution for this problem, 
> but that's just me, and macros can certainly be done as a recipe.

It's a rather special form of macro substitution - I have yet to see 
that "eat up definitions as you substitute" approach elsewhere :-)
(It's also limited: only within a single page, no macro parameters. 
These would definitely be too far ahead.)

The main thrust behind that substitution approach was, however, the 
decoupling of table layout and table contents. Then I found it's also 
useful for setting up administrative pages (e.g. user lists and the like).

I agree that it's probably beyond most casual wiki users, so making it a 
core feature anyway would require some really strong arguments. (Again, 
I'm impressed how easy integrating new markup is in PmWiki - I wish 
other wikis were as modular...)

On a tangent, I'm wondering whether it's possible to enable a recipe on 
a per-group basis. It might be as simple as

   if($Group = 'Somegroup') {
     include_once('local/some_complicated_stuff.php');
   }

in config.php - or am I overlooking something?
The background here being that I'd like to enable that table stuff on 
the administrative pages but not on the pages where the standard user lives.

> That said, I think it's probably a mistake to use & to denote "variables" --
> the poor little ampersand has too many meanings already.  It's already used
> for character entitites (ç) and the separator for query string
> parameters in urls, as well as its standard "and" meaning.  I'd hate to
> be in the case of trying to distinguish "&ccedil" from "ç".

Oh, right.

> I'd suggest continuing the tradition of using a leading dollar sign to
> denote variables.  Yes, it will invite some confusion between PmWiki
> pseudo-variables versus PHP variables versus markups for variables,
> but at least we know it's a variable and there's some hope of unifying
> things in the future.

That might conflict with the usage of PHP variables in the skin template 
files.

Besides, while the dollar sign is certainly intuitive for programmers, 
nonprogrammers most likely never heard of that convention.

Well, I've asked a nontechnical person, and she said that =VARIABLE is 
most intuitive (she would have preferred VARIABLE* since the asterisk is 
traditionally used for footnotes, which are reminiscent of what's 
happening here, but the asterisk has been used for emphasis in mail and 
newsgroup messages, and I don't want to block that markup. Better ideas 
for marking variables are always welcome :-)

Regards,
Jo



More information about the pmwiki-users mailing list