<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body><div style="text-align: left;"><br><div><span class="gmail_quote">On 1/15/07, <b class="gmail_sendername">Patrick R. Michaud</b> <pmichaud@pobox.com> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ## link text can go at beginning<br> ## link to Category but displays as "My cool Categories"<br> [[{My cool }Categor(y){ies}]]<br><br>The idea is that parens identify part of the link target<br>that aren't to be displayed in the link text, while curlies<br>identify things that display in the link text but aren't<br>part of the target.<br><br></blockquote></div><br>FWIW:<br><br>Though I've seen people swearing by mechanisms like these, I think in the end they end up complicating things. <br><br>One other such trick is the [[Group/Page]] vs [[Group.Page]] markup. In my experience only the latter semantics are desirable and I have thus removed the former from my wikis. It's more thing that doesn't need to be learned or explained, lowering the barrier. <br><br>I also found freeing up the / operator allowed it's reuse, besides simplifiying coding. <br><br>In all cases the [[Page | text]] markup will do nicely while not alienating female users. <br><br>As a matter of fact this markup comes a long way into unifying all:<br><br># [[Group.Page]]<br> [|Group.Page] <br># [[Group/Page]] <br> [Group.Page |] <br># [[Group.Page | text]]<br> [Group.Page | text] <br><br>Maybe I should add a 3rd item to this list: automatic line-joining into paragraphs. While in the past there were good motives to do so I think we now have the option of the (:div:) (or >><<) markup. Removing automatic line-joining also allows <br> to be inserted more elegantly. <br><br>Especially new wikis benefit from these changes. Those with a large number of pages may be hard to migrate, but the pmwiki1 to 2 transition has shown this not to be nearly as difficult as imagined. <br><br>I think these 3 examples show how a lighter markup is possible without giving in on features. In all cases a case can be made that only the more experienced users (the group most readily transitioned) would be affected. And I too call upon<br><br> <em>3. Avoid gratuitous features (or "creeping featurism")</em><br><br>to defend my case. I also think Pm had better cal upon philosophy #1 to defend historic motives:<br><dl><dt><em> 1. Favor writers over readers</em></dt><dd><br></dd><dt>Furthermore, I think we've come to the point where Philosophy #2 has become debatable: <br><em></em></dt><dt><br><em></em></dt><dt><em> 2. Don't try to replace HTML</em></dt></dl>As pmwiki really means having something better then HTML to work with! Which means there is a level of support that removes the desire to use (go back to) HTML. Or CSS. <br><dl><dt>Finally number #4:<br><em></em></dt><dt><br></dt><dt><em> 4. Support collaborative maintenance of public web pages</em></dt></dl>in the end means this: put everything into pages: skins, css, javascript and the php code itself. <br><br>Applying this to pmwiki.org I'd very much like to see the code of pmwiki accessible as *webpages*, so I can consult the history to scan for changes that might have affected or will affect my code. Having them locally would be even better. Maybe in a few years patches will be delivered incrementally and I'll be able to set the version to run (the site) simply from a page :-) <br><br>/jm<br><br><br><br><br>-------------------------<br>Pmwiki, the reliable wiki. <br>-------------------------<br><br>Indeed the following is ridiculous:<br></div><br /><hr />Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. <a href='www.live.com/?addtemplate=holiday' target='_new'>Check it out!</a></body>
</html>