<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hans wrote:
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap="">Sunday, July 12, 2009, 7:12:51 PM, Ed W wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Basically *because* you have the flexibility to override
$MakePageNamePatterns, it's then important to be consistent between
"PmWiki" and "Pm Wiki" since both may point to different pages if
people make use of this flexibility
</pre>
</blockquote>
<pre wrap=""><!---->
No. It is possible for an admin to redefine $MakePageNamePatterns
in all kinds of ways, which may be by design totally incompatible
with the page names used in the documentation included in the
distribution. The flexibility I mentioned lies in the default
page name patterns used for links, in that we can use
for instance [[PageListTemplates]], [[page list templates]] or
[[PageList templates]] etc. synonymously.
</pre>
</blockquote>
<br>
You seem to just be arguing that you don't care about any other use
case than the current one?<br>
<br>
Quite clearly there is only one possible $MakePageNamePattern which is
compatible with the current documentation and that's the one that we
are using now - so this rather negates the benefit of being able to
change the thing.. End result is that it's a much less useful feature
than you think it is...<br>
<br>
Look - I sense you are arguing from a theoretical position - just setup
a new wiki and apply the following to your config:<br>
<br>
$PageNameChars='-[:alnum:]';<br>
$MakePageNamePatterns = array(<br>
"/'/" => '', # strip single-quotes<br>
"/[^$PageNameChars]+/" => '-', # convert everything else
to hyphen<br>
"/(^\\-+)|(\\-+\$)/" => '', # trim hyphens front and
back<br>
"/\\-{2,}/" => '-', # trim duplicate hyphens<br>
'/((^|[^\\w])\\w)/e' => "strtoupper('$1')",<br>
);<br>
<br>
What you will see is that it actually works extremely nicely for about
90% of things. The documentation is broken in just a handful of
places, mainly due to inconsistencies which look accidental, rather
than this great big theoretical "feature" that you are postulating. <br>
<br>
Additionally PM has publicly stated that he supports development
towards allowing the URL to be changed to have a "-" (or whatever)
separator. These minor inconsistencies in the documentation are one of
the few remaining things preventing that general direction of
development (I presume you see the benefit of being able to use varied
URL construction functions?)<br>
<br>
<br>
I really don't see why you aren't behind this to be honest? What is
this big theoretical feature buying you in practice? <br>
<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<blockquote type="cite">
<pre wrap="">Additionally arguing not to define the correct answer is just
arguing in favour of ambiguity for the sake of it. Defining
"PmWiki" to be correct and "Pm Wiki" to be inconsistent should hurt no-one?
</pre>
</blockquote>
<pre wrap=""><!---->
My point was that there is no correct way to write a link, even though
there is just one page name per page </pre>
</blockquote>
<br>
Well clearly this isn't always true - PM has already stated that he
wants to see "PmWiki" written as such without a space. The remaining
seems worthy of just bashing out what we think is the "proper noun" and
then go from there<br>
<br>
I hardly see you can call it a feature that parts of the documentation
casually refer to "WikiStyles" and later parts refer to "Wiki Styles"?
Consistency is the bread and butter of strong documentation<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap="">If you look at the documentation index page
<a class="moz-txt-link-freetext" href="http://pmwiki.org/wiki/PmWiki/DocumentationIndex">http://pmwiki.org/wiki/PmWiki/DocumentationIndex</a>
you find a very consistent use of wording in the links,</pre>
</blockquote>
<br>
See - that's my point exactly - all except for a very small amount of
arbitrary (and what appears accidental) deviation every now and then<br>
<br>
Why don't we just set some strong rules now (ie define all the proper
nouns relevant to this project) and push ahead on that basis?<br>
<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap="">But if you read through the documentation pages you often find that
CamelCase words are use for links, possibly to emphasise the exact
page the link points to.</pre>
</blockquote>
<br>
OR possibly because of random inconsistency?!! Why are you assuming
order exists in chaos?<br>
<br>
Here's another equally valid theory:<br>
<br>
PmWiki is a wiki which is moving from a historical basis of being
heavily CamelCased to a new basis where links are explicitly stated.
Some of the documentation was written a long time ago and still has
some CamelCaseLinks left in it...<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap=""> This is done by no means consistently, and
often natural word links are employed as well, to improve readability
by constructuing natural sentences.
</pre>
</blockquote>
<br>
Perhaps you think I am arguing the opposite way?<br>
<br>
Nearly all of PmWiki is now CamelCase free and there are just some
scattered remnants in the documentation. I propose to continue this
cull and remove most of the last few percent of them. <br>
<br>
However, I sense that there are a small number of words that people
still feel are most correct to continue to CamelCase, eg PmWiki. Lets
collect this opinion now and get rid of the rest?<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap="">
I do find one page named badly (inconsistent), which is
PagelistVariables <a class="moz-txt-link-freetext" href="http://pmwiki.org/wiki/PmWiki/PagelistVariables">http://pmwiki.org/wiki/PmWiki/PagelistVariables</a>
All other pages associated with page lists use 'PageList...'
like PageListTemplates. I think the page PmWiki.PagelistVariable should
be renamed to PmWiki.PageListVariable (and all links to it adjusted).
</pre>
</blockquote>
<br>
Excellent - so now we seem to be heading down the same track?<br>
<br>
My question is whether this should be [[Page List Variable]] or
[[PageList Variable]] ? Whilst of no importance with the current file
naming, it clearly has an effect if we want to allow different page
file names! Pick one and then lets be consistent<br>
<br>
<blockquote cite="mid:1957970988.20090712200912@softflow.co.uk"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Finally it DOES matter for people who turn on the $SpaceWikiWords
because it leads to inconsistent presentation. Defining a
consistent set of words not to space will give greater consistency with this option turned on or off
</pre>
</blockquote>
<pre wrap=""><!---->
It does no harm when $SpaceWikiWords = true; will present a link like
'[[PageListTemplates]]' as 'Page List Templates', but a link like
'[[page list templates]]' will still appear as 'page list templates'.
The only thing which may need improving may be to have a mechanism to
keep certain words or letters connected by not introducing spaces
even if WikiWord spacing is turned on, so for instance PmWiki stays
'PmWiki' and not 'Pm Wiki', or PIM stays 'PIM' and not 'P I M'.
</pre>
</blockquote>
<br>
Yes, I was implicitly imagining this feature already existed, but in
any case yes the point is that once these "proper nouns" are defined
they can be excluded from automatic spacing.<br>
<br>
<br>
<br>
Seriously though - try my suggestion above - I'm not asking everyone to
contort themselves to make this work - I'm saying that we gain a useful
feature which seems on the general development path, all for the sake
of changing 1%-4% of the links in the documentation to be internally
consistent<br>
<br>
Regards<br>
<br>
Ed W<br>
</body>
</html>