My users started complaining right away about one annoying thing. They stop writing right away when they need, let’s say bold something, double tap a word, click B and continue writing. Sure, new tap to B stops use of bold — and giving a space, a comma, new word, what ever not to choose before bolding, does the trick.
Far away from major one, though.
To start - this looks really nice!
However, I would like to add a brick to the small wall of comments saying that one should always have an option to toggle back to the “raw” input mode. Maybe I’m old-school 
And a small bug report (kind of expected, but worth pointing out): In the new mode, you have limited options to edit your text with a prompt that focuses on formatting:
Ohh the amount of philosophical debate that comment covers 
Really good! Many users find Discourse “too technical” and I think the WYSIWYG composer might help a lot!
So now “just” implement the WYSIWYG Mermaid diagrams composer!
Or if that’s too hard, I think this is the only one that does not just make the code block colorful, but actually displays something completely different. The two-sides view works well there. I think it should work within the editor, without the need to switch to the old way. Not sure how though.
This is looking a little further into the future than we have fully planned. I think it’s likely that we’ll offer a user preference to enable the Markdown toggle, but that is not set in stone at this point. Appreciate you sharing your opinion here though, it’s helpful input.
It’s an experimental feature, so proceed at your own risk. We ask that you please share any feedback here to keep everything in one place for us, that will make our lives much easier
I can’t repro this. My draft is saved when clicking a link. But, we will be working on a Link UI (see 
Missing features section) so that should help with figuring out how to edit the link.
I can understand the problem you’re describing, but not sure what to do about this. I tested this scenario on Google Docs and Notion, and both of them have the same experience (i.e. after highlighting a word and turning on bold, all the words you type after moving the cursor off that word are also bold). I think this is just a consequence of using a rich text editor and not being able to see as clearly where the formatting ends.
Keyboard shortcuts (CMD+B) are available and writing Markdown still works, if that’s any help. I’ll keep thinking on this though to see if there’s a better solution. How Obsidian handles editing comes to mind but that would not be simple for us to achieve at this moment.
Mermaid diagrams may be a little bit down the road — but noting your interest and adding it as a Missing feature.
I’ve captured the feedback about removing headings 
I can reproduce this with inline oneboxes, I’ll look into it today, just to avoid navigating away until we work on the UI to toggle between links/oneboxes.
I tried copy chat messages to a topic.
Flipping to markdown fixed that, so not major issue at this point.
Chat quotes / transcripts aren’t supported yet, but we’re working on it.
Something I’ve noticed is that double-tapping the space bar on iOS and macOS sometimes isn’t creating a full stop (period) like it should, in WYSIWYG mode.
I originally wrote that it never does it, but it just did it for me. So it seems buggy? Can anyone else confirm?
This seems like a great improvement for us non-tecnical folks, Discourse team. Thanks
I noticed that if I start a line with four spaces, it automatically turns the line into code (and then bolds and italics don’t work anymore).
Will it read the spaces as actual characters if I use up to three in the begining? Still, not enough for my use case. edit: it doesn’t consider the spaces as characters.
Is there a way for the tab button to work as it does in Google Docs and Word? Or to use as many spaces as I want without losing formatting options? This would be especially special when pasting stuff from a Docs file, for example, so it would look closer to how it looked in the original version.
Also, this seems like a good idea:
Also, I don’t usually use colors, but could see it being important to some people. Do you think you will get there?
That’s all from me now. Thanks again!
We’re just being consistent with how it will look like when you publish it – a line started with 4 spaces will convert into a code block when the post gets published.
Not really, no. In the end we’re still building a prettified Markdown to then be cooked to HTML, so only things that can already be done with our current Markdown→HTML processing will be supported in this new editor.
We do have the opportunity to build new content types, of course, but they’ll need to also be supported through raw Markdown, as that’s our source of truth.
I am really enjoying the new composer!
One habit I am having to change is that I can no longer just use shift-up or shift-down to select the current paragraph I am on. I did not realize how I often I do this but I do it all the time, to delete some text or select and move it around.
I now have to use shift-left or shift-right (or shift-cmd-left or shift-cmd-right) to select the last bit of text on the top or bottom line. If that makes sense. Otherwise it starts selecting the next paragraph.
I think this is a step ahead for non-technical users! Though, like @Canapin, it will take me a bit of time to get used to the change 
. A toggle to quickly switch between Markdown mode and WYSIWYG mode would definitely be appreciated.
As others noted, the editing area on desktop could be a bit wider. And I also encountered the problem of not being able to get back to normal text once I have entered a heading - maybe only rendering it once the line is completed and I pressed Enter is an option? (I would appreciate not needing to use the mouse to undo this, and it also feels consistent with how other tags are only rendering once they are completed)
In addition:
I am unable to create multi-level lists
I am not sure how I would indent code in a code block
The contrast of the language dropdown for code blocks is a bit low (screenshot below) - I missed it at first
Entering tables as markdown does not seem to work (when a table has been created in the old editor, it is rendered correctly)
When a table is followed by another block element (like blockquote), it is not possible to insert a new line after the table
It seems, there is no support for footnotes (I think there is also a bug with footnotes in the old editor - if I try to create footnotes 1 and 2, only the first is rendered correctly)
If I paste a picture from the clipboard, I’m not sure how to create alt text, and I also wouldn’t know how to change the size of the image.
I really like the way multi-level lists work. Just start by putting in the markdown as usual and it automatically starts your first bullet. Then press enter to create the next one. Tab to indent. Erase to change from bullet to number, etc. shift-tab to create another bullet.
Ok, thanks! I guess I didn’t try that because of the code block thing and because it doesn’t work in the old editor. But it makes sense the way it works in the new editor.
Reminds me: it actually would be neat if numbered lists would cycle through different symbols (e.g. first level = numbers, second level = lower case characters, third level = roman numerals, fourth level = upper case characters). But I assume this not on the table because it’s not part of the CommonMark or GFM specifications?
I used the new composer a few times recently and I didn’t even remember and notice it was now WISYWIG; I mean by this that it was so natural for me to use it that didn’t think about it while writing 
like the composer was always this way, tho it was not.
I was even not bothered at all with the narrowness of the window. 
A really smooth experience, and I didn’t experience bugs but my use was only basic content (text, quotes, standard formatting).
I don’t know if it’s still the case even with the regular composer, but before, the preview was almost 100% identical to the definitive post. I remember complaining a bit a while ago because the preview width was slightly different of a post width, which made the preview not exactly identical to the posted content.
Now, I’m not sure I would complain if the composer is wider than a post, if it’s more comfortable than before to use. 
Ok, that’s a good point! Having the posted content match the edited content would certainly minimise friction.
In this case, I think I would prefer it if the edited content is on the same visual axis as the posted content, though.
Well, this isn’t print medium, so posted content isn’t for (almost) everybody identical.
I started working on this yesterday, hopefully it won’t be too complicated and we can have something soon…
That chat quoting isn’t a big deal because it mainly affects moderators and admins, who know how to switch back to the old system.
The footnote feature is more important.
To be honest, that was just my point of view, and I really don’t know how things are out there.
It’s funny. My users were complaining about markdown and the lack of WYSIWYG earlier. Now, none of them have switched to the new system. I almost know why. Almost everyone is using mobiles and they were actually complaining about images and couldn’t see anything but markdown.
They don’t use anything else, and we’re back to my old claim: we need a tool to hide and show the toolbar. Regular users are used to the social media style where they just write pure text, send it, and that’s enough. And because Discourse offers that, kind of, they don’t get any incentives to change or try the new system. Except for seeing images in the composer, but my forum isn’t that image-heavy.
Commoners might be a different story, but they don’t know about that magic flip.
