You are not logged in.
As much as I love Textile (it is, afterall, what introduced me to the world outside of \LaTeX text markup) I would love the option to chose something other than textile as my text processing engine. Namely MultiMarkdown. It works in so many applications now and it gets more and more confusing to switch between Textile an Markdown.
What about adding a simple functionality to extend the drop down list in the Admin menu that allows me to select Textile or line breaks to be extensible by a plugin or directly shipping Markdown with Textpattern? I would even volunteer to write the Plugin to do so, if only someone could tell me whether it is possible at all or not :-)
Offline
As this idea keeps popping up I’ve filed an issue to keep it in sight.
I’d rather not bundle any additional text filters with the core but rather provide a versatile interface for text filter plugins and, if energy permits, a user interface to allow publishers to define filter chains.
Try wet_quicklink | Me | @rwetzlmayr | +Robert Wetzlmayr | Repos
Offline
I personally don’t see need for a user interface or chaining options. If and when the filters are implemented by a plugin 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:
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. Adding some sort of interface is in my opinion way too much bloat.
Rah-plugins | What? I’m a little confused… again :-) <txp:is_god />
Offline
+1 for Markdown as a syntax option.
If an option to use Markdown is added, Txp will gain a certain sum of new users. Very happy to see this in discussion as a real potential. Exciting.
Offline
If other text processing engines are to be thought of, I think that a generic approach should be favorable so as to allow almost any kind of engine to be used. Having said this, I have no idea about how difficult (or possible), this would be.
neme.org | neme-imca.org | hblack.net | LABS
Offline
IIRC, Markdown already comes with a textile compatibility method. You’d need to check with the MD documentation for exactly how to do this, but I think it is as simple as renaming the MD file and replacing the textile file with it.
— Steve
Textile | My plugins on GitHub | @netcarver
Offline
I saw this issue is marked as “accepted” on googlecode. Does that mean it will be in 4.5 or do we have to wait for a 4.5+ release?
Offline
stephan wrote:
I saw this issue is marked as “accepted” on googlecode. Does that mean it will be in 4.5 or do we have to wait for a 4.5+ release?
It’s accepted insofar as it’ll appear in core at some point. But 4.5 is now in feature lockdown, bug hunt and issue squash mode, so it won’t be this time round.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern.
Txp Builders – finely-crafted code, design and Txp
Offline
OK, great. That is what I thought – thanks!
Offline
As far as I can remember, past discussion have always revolved around alternate markup filters for the “Write” tab.
Has anyone ever encountered a real user’s requirement to switch away from Textile for the public side, i.e. comment formatting?
Try wet_quicklink | Me | @rwetzlmayr | +Robert Wetzlmayr | Repos
Offline