Is it the Accessible contrast or Dark theme? Is window zoomed/scaled?
I gotta admit, I prefer the older composer. I prefer to have what I typed up on the left, with the preview containing the markdown applied on the right.
I’m using the meta branded theme. Default zoom.
1 Like
I have shared this privately, but I think it is important to share publicly. I am extremely excited about this change, it is transformative to Discourse and opens the door for an enormous amount of communities 
This one got me yesterday, might as well post here.
Once you get into a “HEADING” state, there is no way to easily undo it. Eg type ### text. This is particularly problematic if you kick of a post with a heading and change your mind, you need to flick back to classic composer to undo that.
I wonder if we need a toolbar item for this, that lets you flick a line to “heading 1/2/3 - paragraph” etc.
12 Likes
This is an option, yes. We can also make it so a backspace on the start of a heading can “reset” it, similar to how it currently works with a > blockquote.
3 Likes
It is! But I really like how you can switch back to good ole markdown if you prefer. Nice touch.
4 Likes
I believe this was one of our planned toolbar enhancements, so that should help, but I like Renato’s approach too. It’d be nice to have both options.
2 Likes
So far I haven’t been able to figure this out. I notice some strangeness with the icon when I have Text Size set to “Larger” or “Largest” in the Interface Preferences…can you check what you have that set to to see if that’s potentially at play here?
1 Like
Right, it definitely impacts the icon position:
1 Like
There has been some fixes merged today already, 99% of them by Renato, the last one by me:
- FEATURE: add horizontal_rule rich editor input rule (#31788) · discourse/discourse@d1a8ed1 · GitHub
- FIX: use virtualElementFromTextRange on emoji autocomplete more (#31783) · discourse/discourse@962bdf3 · GitHub
- UX: make an em-dash from en-dash plus hyphen on rich editor (#31787) · discourse/discourse@9b692ed · GitHub
- UX: add title and aria-label to md/rich editor toggle (#31784) · discourse/discourse@159aa43 · GitHub
- UX: remove auto-conversion from .. -> … (#31770) · discourse/discourse@6a80c6b · GitHub
- FIX: Disable composer editor switch when uploading (#31789) · discourse/discourse@979d0ca · GitHub
If I get more done today, I will update this post. Also we will keep updating this topic/the OP generally as things are improved.
9 Likes
Are you planning to eventually remove the markdown-only toggle?
The new editor looks great, and many users will like it, but I strongly dislike using WYSIWYG editors and wouldn’t want to use it myself. If the ability to stay in markdown-only isn’t going to be removed later, it’s a perfect solution.
A user preference to start with Markdown would be nice then (in the future, when rich editor becomes default).
Since ask.discourse.org and search did not show this: whoever wants to test the new editor in his own instance can enable it with
SiteSetting.rich_editor = true
in the rails console.
@lindsey: Are there any concerns about enabling this feature on self-hosted instances?
1 Like
Noting here that the switch remembers your choice on a per-device/browser basis, and is always markdown by default currently.
1 Like
This is great!
As a somewhat technical user, I’ve gotten used to the the semi-wysiwyg standard used by Obsidian and my Vim config where markdown syntax isn’t rendered for the element you are currently creating. For example, when creating or editing a heading you’ll see:
# This is a top level heading|
But as soon as you move the cursor off the line you’ll see:
This is a top level heading
When creating or editing an inline element, for example an italic element, you’ll see:
this is _italic|
then
this is _italic_|
then: this is italic, once the cursor has moved past the element.
That approach takes care of the issue of how to undo a HEADING state, or an ITALIC state once you’ve gotten into it. It also has the possible benefit of not hiding the fact that markdown is being used.
That kind of semi-wysiwyg approach might be more technical than you’re looking for though.
2 Likes
Currently, heading editing is twisted:
If one starts a heading using several ### and one space, one gets into heading mode. After deleting the space via backspace, the # will be shown again, like in obsidian.
After typing some letters into the heading, changing to edit the ## is not possible anymore (which would be great for “markdown input in rich editor mode”).
Currently, it is very easy to lose edits: If one happens to click on an inline link, the new composer will be left without saving a draft.
Clicking on an inline link might be thought of as a way to edit that link.
1 Like
Hey @sam,
Thanks for tagging me in the suggestion thread, pretty pleased with this so far. Great job everyone!
Really looking forward to seeing the final form of the editor.
This was also something I noted. In addition to the width of the editor feeling small on desktop, which also was mentioned in the topic.
The new editor is really cool and will be a great addition. I also think it is important to keep the option to flick back and forth between the raw view and the WYSIWYG view permanent. Maybe would make sense to have the button in the bottom right of the editor window? The toolbar feels more like a place where the buttons “add” something to the text, rather than just change the view.
2 Likes