[Pmwiki-users] Group specifier and free links (was Re: more --signature markup..)
Christian Ridderström
chr
Tue Feb 10 06:40:59 CST 2004
On Mon, 9 Feb 2004, Patrick R. Michaud wrote:
> On Mon, Feb 09, 2004 at 11:37:31PM +0100, Christian Ridderstr?m wrote:
> >
> > Of course, writing that, I realize that putting '/' or a '.' can change
> > the interpretation drastically (e.g. Group/{{bla bla}}). OTOH, I've never
> > quite understood the reason for putting the group outside.
>
> Well, WikiGroups predated FreeLinks by about a year, and when FreeLinks
> were added it was just deemed simpler to leave the Groups on the outside.
I see. Well, I'm not sure I'd want to change it now --- just mention that
it *is* something that feels a bit weird. I remember having problems with
it in the beginning, and I also remember questions being asked on the list
about it.
> Besides, a FreeLink can start to look really funny with the group name
> inside:
>
> {{My special group.my install|ation}}ed
>
> {{My special group/my install|ation}}ed
>
> Both link to MySpecialGroup.MyInstallation and one renders
> as "My special group.my installed" while the other renders as
> "my installed".
Doesn't that impliy new functionality? We can't enter group names like
that today AFAIK, and in general, I thought group names were more
restricted than the page names? I.e. in order for the above example to
be consistent with todays markup they should be:
{{MySpecialGroup.my install|ation}}ed
{{MySpecialGroup/my install|ation}}ed
Although that doesn't look much better to me. OTOH,
MySpecialGroup/{{my install|ation}}ed
is still a bit funny looking to me.
> Plus, the FreeLinkPattern is already hairy enough [1] without trying to
> add groups to it, or figuring out if someone has specified a group on
> the inside or on the outside.
Ok, the implementation aspect again.
>
> If you're willing to say that group names in FreeLinks should be displayed
> in their natural form (and not as the free link text), then it's
> conceivable to add these link patterns via an entry in $DoubleBrackets.
> But it will probably have a big impact on the WikiTrail code and other
> items that depend heavily on the current freelink patterns.
Ok. Maybe something for the future then, after checking with "normal"(*)
users to see how they feel about it.
/Christian
(*) Normal, as in not having become used to the current syntax.
PS.
> 1. For reference, the current $FreeLinkPattern is
Just for fun, I tried understanding it :-) Here's the original:
$FreeLinkPattern="{{(?>([[:alpha:]][[:alnum:]]*(?:(?:[\\s_]*|-)[[:alnum:]]+)*)(?:\\|((?:(?:[\\s_]*|-)[[:alnum:]])*))?)}}((?:-?[[:alnum:]]+)*)";
First I expand it so I can see the structure:
$FreeLinkPattern= "
{{
(?>
(
[[:alpha:]][[:alnum:]]*
(?:
(?:[\\s_]*|-)
[[:alnum:]]+
)*
)
(?:
\\|
(
(?:
(?:[\\s_]*|-)
[[:alnum:]]
)*
)
)?
)
}}
(
(?:
-?
[[:alnum:]]+
)*
)
";
And now I'll see if I can make it more compact by introducing
subexpressions contained in variables:
$FreeLinkPattern= "
{{
(?>
( $tokenPattern $suffixPattern* )
(?: $vbarChar
( (?: $separatorPattern [[:alnum:]] )* )
)?
)
}}
( (?: -? [[:alnum:]]+ )* )
";
$tokenPattern = "(?:[[:alpha:]][[:alnum:]]*)";
$separatorPattern = "(?:[\\s_]*|-)";
$suffixPattern = "(?:$separatorPattern[[:alnum:]]+)";
$vbarChar = "\\|";
I'll now describe the free link pattern using EBNF:
free-link ::= '{{' token *suffix ?('|' *cut-text) '}}' *add-text
token ::= alpha *alnum
suffix ::= separator +alnum
separator ::= +ext-ws | '-' | empty
cut-text ::= separator alnum
add-text ::= ?'-' +alnum
ext-ws ::= whitespace | '_'
empty ::= ()
Some questions:
* Why can <separator> allow *zero* or <ext-ws>, but only one '-'?
* Why allow only a single <alnum> in <cut-text>, but +<alnum> in <suffix>?
Would these rules work just as well?
free-link ::= '{{' alpha *suffix ?('|' +suffix) '}}' *add-text
suffix ::= ?separator +alnum
separator ::= '-' | +( whitespace | '_' )
add-text ::= ?'-' +alnum
--
Christian Ridderstr?m http://www.md.kth.se/~chr
More information about the pmwiki-users
mailing list