I would be interested in someone trying out creating a plugin for something like https://github.com/guardian/scribe , that said the concept of markdown is baked quite deep into Discourse and HTML to markdown engines are all fairly rough.
I don’t see much room moving to StackEdit as we own our editor and markdown pipeline and are constantly adding the features we need to it. We have the architecture to allow for various extensions that stack edit has.
I find CKEditor and the rest of the bohemouth do everything wyswig editors a pretty big problem, but sure people can create plugins.
Transitioning in and out of non-markdown editor plugins will be a massive pain though.
I don’t quite understand all this… but may be the transitioning would be easy if the Ckeditor is converted to using bbcode?
I think that is what Vbulletin did with the CKEditor, they code it to use bbcode or something like that, they didn’t just install the editor and use it out of the box. I think they said it took them 2 month to convert the editor’s tools and functions to bbcode.
I think many knows that : ) but those who are used to IPB, or Vbulletin’s functions and features which are basically dominating the forum market, many of them might not look into Discourse if it isn’t competing at the same level or better and i think that is Discourse’s goal to become the most popular forum platform.
So wait, you’re suggesting that Discourse take 2 months to overhaul an existing project? Just so that people have more choice of text editor?.. (It may take less time, because Markdown takes HTML, but – WYSIWYG editors unanimously produce ugly HTML, and it will be tough for any communities to transition to any other forum software, past, present, or future, if the posts are in HTML.)
As @sam said, “people can create plugins.” From looking at the code, I can vouch that it will be possible to completely overhaul the editor in a plugin.
Maybe a better route would be to work towards getting those extensions that exist for other editors built for Discourse.
This was based on what VBulletin staff said but remember VB admin system is much more feature rich and complicated than Discourse, so that is why it took them 2 month to convert the editor into bbcode and add the ability to add custom bbcode to the editor through the admin system and so on - a much more complicated approach that also works with user group permission.
I personally would love to see the CKEditor being integrated well with Discourse. One of the essential elements of sharing is how you are going to create topics and having the needed tools that makes creating topics a fun and deep experience.
Actually the existing edit field is perfectly fine, but it looks like you’re all trying to solve a user preference matter on a site-wide basis. The solution is not to force your preferred editor on every user of the site you’re running (let alone every site running a Discourse instance), the solution is for users to be able to edit any text field with the editor of their choice.
Ah, I hear you say, but what if I want to use Chrome? Well, I don’t use it so I can’t verify this personally, but apparently this Chrome extension will do the job. It looks like it takes a little more to configure, but otherwise should be similar.
And what of Internet Explorer? Well, really you should probably stop that, but if you must … there’s this.
Oh, if Emacs ain’t your thing, that’s fine. You can run pretty much any text editor you like through these extensions. Editors that run inside a terminal may require a little shell scripting trickery, but otherwise you can do what you like.
I’m noticing various simple editor controls missing (font, size (besides h1/h2), font color, alignment, float a block/image left/right, removing formatting, etc. Plus lots of problems with undo (in particular not undoing!).
I know alot of these can be addressed by using markdown or html, but I don’t expect my users to learn those. They expect simple editor controls.
I see this as a major problem. The creation of quality attractive content is the first step!
Search for things like “rich editor” and “wysiwyg” and you’ll find a lot of the old discussions covering this subject. In short, it is a seemingly simple problem that is incredibly difficult to execute in practice. It is for good reason that most popular social networks pretty much stick to plain text.