Patrick R. Michaud
pmichaud at pobox.com
Tue May 30 15:22:49 CDT 2006
On Tue, May 30, 2006 at 11:14:21AM -0700, Pico wrote:
> I am trying to think through a broad proposal for a system that would
> make it easier to define, maintain and reference common terms,
> including terms that contain special characters, such as "(:markup:)"
Thanks for starting this -- it's very timely and useful.
I'll start with a different perspective on this problem. I tend to
want to do things with the tools that already exist, as opposed to
creating new tools for every situation we can envision. This was
true for creating/maintaining the FAQ, and I think it might apply here
My first reaction is that if we (temporarily?) suspend the requirement
that terms be allowed to contain special characters, then we can
do things using wikigroups. For example, [[terms/title]] can
easily link to a page that describes the meaning of the term "title";
the page describing "title" can easily have full markup.
Or, just put the "Terms" wikigroup into the $PagePathFmt, so that
[[title]] can automatically find it there.
It wouldn't be so easy to have multiple definitions on a page,
but one could use (:include:) or (:pagelist:) to combine
several definition pages into an overall summary or list of terms.
It'd be trivial to use (:pagelist link=terms/title:) to find all
of the pages that reference the "title" term, or to come up with
a fmt= parameter that promotes pages in the Terms/ wikigroup to the
top of the search result list.
(Or, instead of using wikigroups, one could use InterMap links,
such that term:title would generate a url for the definition of
Looked at another way, for a very long time PmWiki (and many other
wikis) would respond to a request for a non-existent XYZ page
with the text "Describe XYZ here." In other words, the whole notion
of a wiki is to use pages to map terms directly to a description
I agree there are some details that would need to be handled.
For example, perhaps we need to find a way to allow more special
characters into pagenames (although my first thought is that
this makes searching more complex, not less).
Ultimately I think I'd prefer a strategy that allows us to achieve
the desired results using the existing frameworks we already have
available, as opposed to layering yet another index, markup, cache,
and search framework on top of PmWiki. For any particular capability
there's a tendency to want to build a complete support system
around it, when what we really want to do is extend our existing
systems to be able to handle it (again, the FAQ is an example of
More information about the pmwiki-users