Markdown syntax highlighting in post editor

[pipkin (Thijs)]

Would it be hard to replace the default post editor textarea by a markdown syntax highlighter?

Or am I missing the option somewhere?

You have already beautifully implemented this for css in the admin styles editor:

[Falco]

Isn’t that already achieved by using the code block, which gives you syntax highlighting in the preview area?

[pmusaraj (Penar Musaraj)]

This is an interesting idea, the goal would be to have syntax highlighting in the textarea (i.e. the left side of the composer) so you could see if you’re making any markdown syntax mistakes. Yes, code blocks do the same in the preview, but you won’t see any markdown mistakes, for example. And some complex markdown would be easier to scan, post with lots of tables, uploads, links, headings.

I’m not sure it’s easy to do this, though. Our admin screens use the ACE Editor, and I don’t think we can just drag and drop that on the post composer.

[pipkin (Thijs)]

Yes, this is exactly my use case.

It gives a very direct feedback about your syntax: you don’t have to look to the right pane every other second to check if you aren’t making trivial syntax mistakes.

It would give a bit more structure for those who are less apt in Markdown (any beginner).

Of course you still have the rendered html on the right side of the composer window.

I would see no immediate disadvantages to this, especially if it’s an option.

PS: Apparently there’s not even a Markdown syntax highlighter installed for codeblocks :

# Markdown codeblock's syntax...

... unfortunately ...

- isn't
- highlighted

**at all**!

EDIT 2 hrs later: Fixed by @pmusaraj

[pmusaraj (Penar Musaraj)]

Oh, good catch! Looks like we’re missing some styles for the markdown highlighter.

[Falco]

Using a full blow editor for “just” markdown isn’t a bit too much?

In my opinion, using a markdown semi-wysiwyg is more aligned to the OP needs, like for example https://ui.toast.com/tui-editor, Playground | Milkdown, etc.

[pipkin (Thijs)]

Those two look great!

However, I could imagine that the simpler Milkdown would be better suited since it’s okay if the editor gives a more ‘underwater screen’^[1] feel, as you’ve got the preview on the right anyway.

---

1. Yes I vividly remember WordPerfect ↩︎

[pmusaraj (Penar Musaraj)]

Yeah, any one of ACE, TUI, Milkdown is a very big change, they all would need to replace the textarea with contenteditable. Worth an experiment, for sure, but in core it’s a big project.

[pmusaraj (Penar Musaraj)]

PR is up with a fix for the missing markdown highlighting: UX: Update highlight.js styles by pmusaraj · Pull Request #23999 · discourse/discourse · GitHub

[sam (Sam Saffron)]

Just to expand, first that this is something I really want core to support but also worth expanding on the complexity.

Discourse core uses many many APIs against TEXTAREA directly, @mentions, toolbar inserts stuff into the TEXTAREA, uploads, cut and paste images and more.

This is all not abstracted away and assumes it is talking to a TEXTAREA. Adding a contenteditable there direct would mean it would need to also properly and very accurately simulate a TEXTAREA, something that is likely to fail. We need a fair amount of work to create some sort of provider framework so we can swap things in.

See also:

More advance editor should be here?

I have some exprence in taking notes of math in the Editor: StackEdit, while the discouse editor (what’s her name?) is my first forum editor that support markdown and mathjax at the same time with perfect preview, it seems that there are still have some space to make it more perfect, compare with StackEdit: a table of content guide of a rather length topic: in stackedit, we can just put a shortcode called [toc] to make a table of content with links the particial render of mathjax is also qu…

Who would prefer a standard wysiwyg to markdown?

I just saw an interview with Michael Pryor of trello: At one point he says: We added markdown in Trello which in retrospect, was a mistake because it’s a developer centric feature in a non developer focused product. We overcame it by adding guidance on how to use markdown within the app, but users sometimes still get confused. I’m curious to know what the feeling out there is about the use of markdown in Discourse. Am I the only one who thinks discourse would appeal to many more people i…

Highlighter is certainly a great first move in this direction cause you don’t have to worry about bi-directional markdown to text mapping.

There may be some ninja hack where you can hide the TEXTAREA and then render a contenteditable on top of it, ferrying events to the original, but even that would require a re-implementation of @mention positioning.

[pipkin (Thijs)]

@Who would prefer a standard wysiwyg to markdown?

trello

I must be honest here: now that I’ve seen the Trello editor, Discourse feels a bit 2000’s on the editor front:

It think this sort of thing is important.

Note: It is still 100% accepts Markdown syntax.

[Tris20 (Tristan)]

@pipkin

I must be honest here: now that I’ve seen the Trello editor, Discourse feels a bit 2000’s on the editor front:

Personally not a fan of this. It’s far too cluttered. I love that the editor in Discourse is visually clean. All I really see is text, and the rendered stuff is out to the side where it belongs.

Back to the main point of syntax highlighting though, this is something I would also love to see. At the very least I would love # Headings and ## Subheadings to be highlighted in some way. I can’t tell you how often I search through my longer posts, where the preview and editor are misaligned, and it takes me ages to find where my related # heading is.

For me just making # Headings bold, or a particular colour in the editor side of the composer would be a massive improvement.

[Jagster (Jakke Lehtonen)]

@Tris20

rendered stuff is out to the side where it belongs

It is, isn’t it?

These editors are made for devs and coders and are really confusing for ordinary ones.

But it is what it is and is too deep in the core to change. Like draft question

Anyway — off topic etc.

[angus (Angus McLeod)]

@sam

We need a fair amount of work to create some sort of provider framework so we can swap things in.

Is this any closer to happening?

Context:

Rich Text Editor Plugin

Hey there @Rohail_Altaf, this will be a large and challenging job. I may be interested, however I have a few questions first. Could you elaborate on this a bit. How about: Interactive elements outside the composer that insert content into the composer (e.g. quotes). @mentions. Emojis. Inserting dates and times. Right to left support. Onebox support (or equivalent “rich link” support). Tables. If you could enumerate your exact list of expected features that would help, as it will likely infl…

[sam (Sam Saffron)]

We have started work in this area @lindsey will share information as we progress

[nathank (Nathan Kershaw)]

This is very good to hear - using markdown is great for our power users, but quite a learning curve for the majority of our less-than-super-users and would go a long way to making our community more accessible.

[angus (Angus McLeod)]

Hey @lindsey, I don’t want to rush you in any way, but I thought I might just ask if you were able to share the following:

1. Whether the changes will include interoperability / a framework to allow plugins to develop editor solutions.

2. Relatedly, whether you’re looking at developing your own rich text editor, e.g. in a plugin.

3. A rough sense of what timeline you’re looking at for 1 and / or 2.

The context for me is the approach to and timeline of this potential project

Rich Text Editor Plugin

Hello Discourse Developers! We’re looking for an experienced Discourse developer/agency to create a plugin that replaces the default Markdown editor with a WYSIWYG editor, preferably Quill or similar, for our community. Project Requirements: WYSIWYG Functionality: Replace the default Discourse Markdown editor with a WYSIWYG editor (Quill or similar). Feature Parity: The WYSIWYG editor should support all essential formatting options currently available in the native Markdown editor (bold, …

@Rohail_Altaf and I are attempting to think about how best to approach this, particularly timeline wise. Nevertheless, I completely understand if you’re not able to share that at this stage.

[lindsey (Lindsey Fogle)]

Hey Angus — sorry for the delay here, we’ve been out at our company’s annual retreat in Tokyo!

I can’t answer with too many specifics right now as we’re still nailing down implementation details. I think we should have that figured out in the coming weeks, at least well enough to answer these questions, so I’ll check back in once we know more.

[sam (Sam Saffron)]

Discourse is now shipping an experimental WYSIWYG composer

Test our new composer on Meta!

We have been working on a new rich text editor mode for our composer so that it’s easier to write on Discourse. We’re now ready to start testing this mode out on Meta to get more feedback from our community on this feature! Our implementation builds upon the excellent ProseMirror and its non-core Markdown module, using the module’s schema, parsing, and serialization definitions as the base for further Discourse-specific features. This topic will serve as both a guide to testing the new compose…

This infra also makes it possible long term to apply syntax highlighting on markdown if we want to go down that path, it becomes a lot less necessary though with the new composer.

For example the new composer now allows you to apply syntax highlighting to code while you are typing it!