GoogleCodeExporter
commented
9 years ago I personally don't see need for a user interface or chaining options. If and
when the filters are implemented by a plugin, plugin's own load order can be
used, and things as purifying (or any other post-processing) could be done by a
persistent hook, ran no matter what processing option is selected by the end
user.
As the whole deal goes, as bare minimum probably needs:
* some changes to how the article markup option is stored. Instead of the
integer use_textile, some unique identifier is probably needed. A column that
stores a prefixed unique identifier assigned for a text filtering
stack/callback.
* registering method that adds an extra markup options to the Write pane, and
registers to a callback event on the current Textiling location. One that
passes content by reference.
Persistent processing/filtering could hook to the callback event directly
without adding options to the markup option, while registered markup processors
appear in it.
In my opinion that should be enough to allow plugins to change the processing
method from Textile to something else, or add additional sets.Original comment by jukka.svahn@rahinaa.biz on 5 Jun 2012 at 8:12
Original issue reported on code.google.com by
r.wetzlmayron 5 Jun 2012 at 7:17