I can guess what the answer to this will be, but I'm going to ask
anyway.
I'm a big fan of m4. I use it for many things, and have done for about
eight years. It has its warts (and some of them are truly ugly), but
for my money it's a good general-purpose macro processor.
I use it so much that it's painful to produce something like a web
site without the benefit of macros. I'm (somewhat) aware of templates
in mediawiki, but these don't seem to offer me the ease and
flexibility of m4 macros. (Maybe I'm mistaken here - I'd be delighted
to hear that.)
So my question is how much thought has been given to allowing page
authors to indicate that their content should be run through a filter
(or filters) such as m4?
Security will of course be a major concern. But, there are sites that
are only authored by trusted users, and there are also approaches to
dealing with insecure things (like calling m4 and undefining dangerous
functions (e.g., syscmd, esyscmd, maketemp) on the command line. One
would also (perhaps) have to consider things amounting to denial of
service attacks on the wiki server by causing filters to go into an
infinite loop (this could perhaps be controlled by setting an alarm on
the child forked to handle the filtering).
In the general case you can imagine (imagining is free after all)
something like
<filter command="m4 -arg1 -arg2">
text
</filter>
or, to address the question earlier about doing line wrapping,
<filter command="fmt">
<pre>
text
</pre>
</filter>
and the wiki admin would get to set the list of acceptable "safe"
filters (and possibly their arguments) in the wiki config file.
The filter would be run and the output, if any, would replace the
<filter></filter> tags. stderr output could appear too, as happens
when the code that processes TeX formulae hits a snag.
FWIW, I changed mod_wiki to allow m4 pre-processing of pages that
started with a certain indicator.
Have people done things like this? Have ideas like this, which I'm
sure must have come up in the past, been rejected once and for all?
Regards,
Terry.