doc/todo/enable_arbitrary_markup_for_directives.mdwn

   1 One of the good things about [PmWiki](http://www.pmwiki.org) is the ability to treat arbitrary markup as directives.
   2 In ikiwiki, all directives have the same format:
   3
   4 \[[!name arguments]]
   5
   6 But with PmWiki, directives can be added to the engine (with the "Markup" hook) with the usual name and function passing, but also with a regexp which has capturing parentheses, and the results of the match are passed to the given function.
   7 Would it be possible to alter the "preprocess" hook to have an optional regex argument which acted in a similar fashion?
   8
   9 For example, one could then write a plugin which would treat
  10
  11 Category: Foo, Bar
  12
  13 as a tag, by using a regex such as /^Category:\s*([\w\s,]+)$/; the result "Foo, Bar" could then be further processed by the hook function.
  14
  15 This could also make it easier to support more styles of markup, rather than having to do all the processing in "htmlize" and/or "filter".
  16
  17 -- [[KathrynAndersen]]
  18
  19 [[!taglink wishlist]]
  20
  21 > Arbitrary text transformations can already be done via the filter and
  22 > sanitize hooks. That's how the smiley and typography plugins do their
  23 > thing.
  24 >
  25 > AFAICS, the only benefit to having a regexp-based-hook interface is less
  26 > overhead in passing page content into the hooks. But that overhead is a
  27 > small amount of the total render time.
  28 >
  29 > Also, I notice that smiley does such complicated things in its sanitize
  30 > hook (ie, it looks at html context around the smilies) that a simple
  31 > matching regexp would not be sufficient. Furthermore, typography needs to
  32 > pass the page content into the library it uses, which does not expose
  33 > regexps to match on. So ikiwiki's more general filtering interface seems
  34 > to allow both of these to do things that could not be done with the
  35 > PmWiki interface. --[[Joey]]
  36
  37 >>You have some good points.  I was aware of using filter, but it didn't occur to me that one could use sanitize to do processing also, probably because "sanitize" brought to mind removing harmful content rather than doing other alterations.
  38 >>It has also occurred to me, on further thought, that if one wants one's chosen markup to actually be processed during the "preprocess" stage, that one could do so by converting the chosen markup to directive-style markup during the "filter" stage and then processing the directive during the "preprocess" stage as per usual.  Is there a tag for "no longer on the wishlist?". --[[KathrynAndersen]]
  39
  40 >>> Yeah, sanitize is a misleading name for the relatively few things that
  41 >>> use it this way.
  42 >>>
  43 >>> While you could do a filter to preprocess step, it is a bit
  44 >>> of a long way round, since filter always runs just before
  45 >>> preprocess.
  46 >>>
  47 >>> Anyway, guess this is [[done]] --[[Joey]]