Markdown support for MarkItUp [#1026370]

Why does MarkItUp only support html?
I wanted a simple editor with non-html syntax, because wysiwyg editors like tinymce produce the most horrible markup I've even seen. It's not very standard and hard to migrate into other formats.

Then I saw this demo of markItUp http://markitup.jaysalvat.com/examples/markdown/
One of the markItUp's best selling points is killed when running in this environment.

Also half the buttons are missing, there are only six of them.

I tried a patch for this, it didn't work. There should be an option within the wysiwyg profile to use markdown or wiki or whatever you like. This might not work with all the html filters but so what.

Comments

Comment #1

twod

Swedish

Sweden

commented 14 January 2011 at 03:44

MarkItUp's markup/button sets are delivered as a JavaScript file which by default defines a global variable called mySettings.

Adding support for this in Wysiwyg module is tricky for a number of reasons. One of the largest problems is that it's not possible to use more than one markup set per page, simply because including more than one will overwrite that global JavaScript variable.
One of Wysiwyg's goals is to avoid forcing users to modify files distributed with the editor library for them to be usable at all, so those changes will not be accidentally overwritten when upgrading the editor.

A second problem is within Wysiwyg itself. It is based on the old TinyMCE module and does not yet have callbacks to let editor implementations modify the profile configuration form and only supports vary basic settings for now. The GUI has to stay identical for each editor until we get that resolved (will be done as part of letting users change advanced settings) and we'd rather not add more widgets that won't work for all editors to it now. It's already hard enough to keep track of which ones work with which editors.

Once the above issue is resolved, and we've managed to tackle another big issue concerning how toolbars are handled, we might be able to add better support for this editor's way of handling things.

Ideally, users should just be able to download markup sets, extract them to "myMarkupSets"-folder and select them when configuring their editor profiles. We might be able to add support for creating a new custom markup set via Wysiwyg's GUI by that time. But we'll most likely not be able to read a preset button configuration from a markup set and let you customize it via the GUI, as that would almost require us to implement a JavaScript parser in PHP, just to be sure we can interpret the files correctly.
Instead, once a markup set file has been chosen, the GUI for configuring a toolbar would be disabled with a notice that it's being overridden using hardcoded settings.

Anyone who feels up to the challenge is of course welcome to tackle integrating markup set handling with the editor. I'm just saying that given the time I have available to spend on this project, I would like to focus on improving Wysiwyg's core first, so tasks like these have less obstacles to overcome in the future.

Hope that clears things up a bit.