[pmwiki-users] Parentheses in links

J. Meijer commentgg at hotmail.com
Mon Jan 15 11:44:02 CST 2007


On 1/15/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:    ## link text can go at beginning    ## link to Category but displays as "My cool Categories"    [[{My cool }Categor(y){ies}]]The idea is that parens identify part of the link targetthat aren't to be displayed in the link text, while curliesidentify things that display in the link text but aren'tpart of the target.FWIW:Though I've seen people swearing by mechanisms like these, I think in the end they end up complicating things. 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. I also found freeing up the / operator allowed it's reuse, besides simplifiying coding. In all cases the [[Page | text]] markup will do nicely while not alienating female users. As a matter of fact this markup comes a long way into unifying all:# [[Group.Page]]      [|Group.Page]   # [[Group/Page]]           [Group.Page |]  # [[Group.Page | text]]      [Group.Page | text]  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. 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. 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   3. Avoid gratuitous features (or "creeping featurism")to defend my case. I also think Pm had better cal upon philosophy #1 to defend historic motives:   1. Favor writers over readersFurthermore, I think we've come to the point where Philosophy #2 has become debatable:    2. Don't try to replace HTMLAs 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. Finally number #4:   4. Support collaborative maintenance of public web pagesin the end means this: put everything into pages: skins, css, javascript and the php code itself. 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 :-) /jm-------------------------Pmwiki, the reliable wiki. -------------------------Indeed the following is ridiculous:
_________________________________________________________________
Get the Live.com Holiday Page for recipes, gift-giving ideas, and more.
www.live.com/?addtemplate=holiday
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20070115/e2b4c74d/attachment.html 


More information about the pmwiki-users mailing list