MoinMoin: NeilPilgrim

Neil Pilgrim

Email: <moinmoinhomepage AT SPAMFREE kepier DOT clara DOT net>

Installed MoinMoin recently, after being exposed to various wiki-type sites and systems.

Potential MoinMoin Improvements

(Until I check out the specific pages for this sort of thing)

• improving subpages

  NOTE: in what follows, with a subpage of foo/bar/baz the basename is baz, the path being foo/bar[/] and the fullname being foo/bar/baz

  • add option for rendering subpage separators as other characters/symbols/icons
    • eg. use ": " instead of "/", so that partone/parttwo/here is shown as "partone: parttwo: here" (eg. in page titles)

  • add option so that subpage links can be rendered differently (possibly with above subpage-separator idea), specifically without needing extra markup to rename links - basically make subpages easier to use. Add more about motivation here

    NOTE: I'm not sure what of this is in standard MoinMoin - please check!. This could involve:

    • implicit relative link display (change this to characterise different linking methods).

      Link (with or without ([""]), etc.)	On page	Rendered as	Comments
      partone/parttwo/here	partone/parttwo	here
      partone/parttwo/here	partone	parttwo/here
      partone/parttwo/here	some/where/else	partone/parttwo/here	current behaviour
      partone/parttwo/here	partone/parttwo/there	there?
      /here	partone/parttwo	here

    • icons -- Icons could be used to indicate different subpage trees (like with different wikis), or if a page is a sibling/parent/both/non-relative and so on.

    • tool-tips -- Subpage text could show the basename, with a tool-tip showing the fullname

    • hover-expansion -- hovering over a link (at all, or for some period of time) could change display from the basename to the fullname, possibly with css (or js for timed display)

• automatic renaming of links when pages are renamed (moved)
  • on the same site - maintain some kind of cache of links to pages?

  • on other sites (wikis) - use email subscriptions? needs security limits, if at all possible, just a crazy idea

  • potential problems:
    • need to handle subpage links and other relatives links, eg. /Foo and ../Foo

• formatter functions don't seem to handle classes, so you can't do <strong class="error"></strong> (which seems to be popular in some shipped external macros), how best to add this?

  • one use for this seems to be to output errors to the page content (whereas warnings are put into the message-box?), so maybe a general formatter.error_message(%s) would be a good idea? This means a standard style tag can be applied by the formatter, rather than relying on discipline of authors to always use class="error".

  • Such a formatter function is already present: sysmsg ! However in the html formatter it surrounds the tagged text with <div class="message"></div>. There is no css in the shipped themes which matches this class! Examining the source files it is obvious that the css, and some macros, uses class="error" to highlight text, which in html is rendered with color: red. To solve these problems I have made the following patch against the latest moin 1.5 snapshot: http://www.kepiernet.ukfsn.org/moin/moin_sysmsg_strongreduction.patch.
    This patch:

    • adds font-weight: bold; to themes, to match the 'strong' used in some macros (I believe it looks good, this is open to discussion)
    • alters text_html.py to make the class of sysmsg div's be "error" instead of "message" (triggering the styling as it should)
    • tweaks some macros to use sysmsg instead of html-specific tags (using shorthand for formatter in one place where otherwise it wasn't, but where it was used a lot)

  • Open points:

    • Include.py (macro) still uses <strong>, for a warning - I was not sure if it was appropriate to change the class to be error? sysmsg could take an optional 'show as warning' parameter (assuming errors are most common), with extra css code, but is this really necessary? is such warning code appropriate to tag as an 'error' or not?

    • I used the 'formatter.sysmsg(1)+formatter.text('...')+formatter.sysmsg(0)' pattern, which seemed to be common in the source, rather than something like '"".join( [formatter.sysmsg(1), formatter.text('...'), formatter.sysmsg(0), ])', which uses the list merging which I've been told is more efficient - but is longer and less widely used. Which is better?

Please add any comments here

CategoryHomepage