Test our new composer on Meta!

[pfaffman (Jay Pfaffman)]

Hey @lindsey.

Could you update the OP to include this? I almost did it myself, but thought it might be rude.

@thoka

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.

[Heliosurge (Dan DeMontmorency)]

@sam

The change only takes effect on sites with rich editor enabled, and should be live here in 20-40 minutes.

Where do we find the option to enable the rich editor? Only found an option to convert rich text to markdown

[Heliosurge (Dan DeMontmorency)]

@thoka

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

That explains why I can’t find the setting.

Should be moved to GUI toggle in experimental.

[tobiaseigen]

Wow the composer has come a long way.

I noticed a few small things using it to write a longer report just now, with alot of copying and pasting and fiddling with content:

1. if you paste in a link on its own line, then follow it with some text, it will remain oneboxed. there seems to be no way to remove the onebox and have the link just show as though it were later in the line, after some words. workaround seems to be to type the following text first then go back to the beginning of the line to paste in the link.

2. selecting some text and then choosing “Hide details” from the menu causes your text to be overwritten. In the markdown composer it just makes the selected text hidden. (See screencasts below)

3. I will test it again here but in another topic I used hidden details and while the toggle works it is expanded and showing the hidden text by default. You want it to be hidden by default.

Summary

I want to hide this text

[renato (Renato Atilio)]

@tobiaseigen

You want it to be hidden by default.

This is “intentional”, but I see it may be confusing – it’ll set the bbcode open attribute following what you have in your editor view.

Default open

Yes

Default closed

No

[tobiaseigen]

Ohhhh.. I had no idea about that bbcode open option. I have never wanted them to be open. I can verify that it works as you say.

[nolo (Manuel)]

@lindsey

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.

@lindsey

At this point, we do not have specifics on how both versions of the composer will be supported longterm (e.g., whether composer type will continue to be controlled by site setting, left up to user preference, or something else).

I’d find it best if the availability of composer type can be set as a site setting. And when both are enabled, users can pick their composer in a user preference.

I wouldn’t like the toggle option on the composer as a longterm feature. It makes perfect sense now for testing on meta, but it would pretty much go against the goal of simplifying the composer experience.

[alltiagocom]

I few issues I noticed with the rich text version:

1. When I’m creating the post and I add preformatted text, I see this:

and when I post it, I see this, so there’s no match, which is not good:

At least with markdown we can pick single line or multiline with the single tick or 3 ticks. But now with the monospace option (which I’m not a fan of), it’s a bit of a conflict…

2. If I try to use markdown, in this case the single tick vs 3 ticks, I get a weird behavior. If I use a single tick first, it works, and when I use 3 ticks after that, it also works:

But if I try to use 3 ticks right again, I get this:

But this doesn’t happen often, so I don’t know what causes it.

3. It would be great, in the rich text editor, if the Bold and Italic buttons would look “selected/pressed” when the text cursor is in a place where the formatting is being applied. The italic text is more obvious, but the bold not as much. But most importantly is when the text cursor is not in the middle of a word, but after it. “When we type will it be formatted?”
4. This one is just a suggestion, just because to me right now the composer being aligned to the middle, kinda “feels” weird to me. What if it was aligned with the edges of the sidebar and the window on the right? Something like this:

To me, it just feels that it flows better with the rest of the content.

[renato (Renato Atilio)]

@alltiagocom

I get this

Sorry, I don’t follow.

@alltiagocom

would look “selected/pressed”

This will come soon:

@lindsey

Toolbar tweaks for accessibility, indicating which formatting button is in an active state

[seanblue]

I haven’t read all the comments, so apologies if I’m repeating anything that has already been said.

I generally find WYSIWYG editors to be a bit janky, so I tend not to use them. That said, here are some things I’ve noticed already.

1. The fact that a single Enter press is treated as two Enter presses from the markdown editor is a tad jarring. I suppose this isn’t the first time I’ve seen this approach, but if people can toggle between markdown editor and rich editor, the inconsistency might get confusing. Not everyone will necessarily know that Shift + Enter will act as a single Enter does in the markdown editor.
2. Making a header section (e.g. typing # followed by space), then typing some characters, then deleting those characters causes the scroll bar to scroll up for no apparent reason. This only happens if the editor is scrolled all the way down.
3. Supporting adding backticks in reverse order is incredibly important. It’s not uncommon to decide to add backticks for formatting after already typing out a word. Sometimes it’s much easier to add the trailing backtick before adding the leading backtick. This does not work right now in the rich editor. I run into this one all the time in Microsoft Teams (which is an example of a terribly implemented WYSIWYG editor) and it’s very frustrating.
4. When working with a number list or bullet point list, if the curser is on the line after the list has ended, hitting Backspace will add a new list item. This isn’t a problem per se, it’s just a bit unexpected.
5. When working with a mix of code formatted text (backtick) and not, it’s impossible to type plaintext directly after the formatted text when revising what you already wrote. This isn’t a common case, but it does happen sometimes (e.g. formatting a variable name, but needing an s for pluralization or an apostrophe immediately afterwards; again, not common but I have run into it multiple times).
6. There’s no indication of what formatting option is active. Some things like headers will be somewhat obvious based on the cursor size, but other things like bold, italics, and code formatting are not. This is a common source of frustration for me since it can result in me typing something and having to delete it or fix the formatting afterward. The specific case I just ran into was typing formatted code and then deleting it all because I changed my mind on what to write. I then went to add another backtick to write something else in formatted code and it actually displayed the backtick because it was already in that mode and thought I wanted to type the raw backtick character.

[alltiagocom]

@renato

Sorry, I don’t follow.

It was probably a glitch, because I can’t reproduce it now, or maybe something specific needs to happen for it to behave like that. Basically, as you can see, the 3 ticks were rendered as text, inside single ticks, hence the dark background. Then the second time I would add 3 ticks, right underneath the previous one (the 3 ticks rendered as text inside digle ticks), it would then create the code block as expected. Hope it makes sense now?

I also just noticed that markdown in rich text mode doesn’t work as expected. Look at this where the single ticks are not affecting the text `test`, but the 3 ticks are doing their job.

[lindsey (Lindsey Fogle)]

@seanblue

• The fact that a single Enter press is treated as two Enter presses from the markdown editor is a tad jarring. I suppose this isn’t the first time I’ve seen this approach, but if people can toggle between markdown editor and rich editor, the inconsistency might get confusing. Not everyone will necessarily know that Shift + Enter will act as a single Enter does in the markdown editor.

Editors are relatively split on this option. For example, Google Docs has Enter = line break, but Notion has Enter = paragraph break. I think your point about consistency between Markdown mode and the rich text editor is fair, though.

@seanblue

• Making a header section (e.g. typing # followed by space), then typing some characters, then deleting those characters causes the scroll bar to scroll up for no apparent reason. This only happens if the editor is scrolled all the way down.

I can’t reproduce this with your current steps, could you provide browser details and more detailed instructions or a recording? Thank you!

@seanblue

Supporting adding backticks in reverse order is incredibly important. It’s not uncommon to decide to add backticks for formatting after already typing out a word.

@seanblue

When working with a mix of code formatted text (backtick) and not, it’s impossible to type plaintext directly after the formatted text when revising what you already wrote.

We’re working on some fixes to how inline code works in the editor, which should resolve this problem.

@seanblue

When working with a number list or bullet point list, if the curser is on the line after the list has ended, hitting Backspace will add a new list item. This isn’t a problem per se, it’s just a bit unexpected.

Good catch, I agree that’s unexpected. I’ll report to our team to fix.

@seanblue

There’s no indication of what formatting option is active.

We’re working on this!

[pfaffman (Jay Pfaffman)]

@lindsey

Editors are relatively split on this option. For example, Google Docs has Enter = line break, but Notion has Enter = paragraph break. I think your point about consistency between Markdown mode and the rich text editor is fair, though.

AND discourse has a setting that switches between those two modes Traditional markdown linebreaks “Use traditional linebreaks in Markdown, which require two trailing spaces for a linebreak.” – so I think that both editors should obey this setting.

[pfaffman (Jay Pfaffman)]

@thoka

@lindsey: Are there any concerns about enabling this feature on self-hosted instances?

It got hard to find, and even after finding it at least five times, I still can’t remember it, so I added it to the OP with the admonition that it’s at your own risk.