LessWrong is rolling out a new (experimental) editor.
Why? Our primary motivation for implementing a new editor is to make it easier for us to quickly build new integrations and customizations, particularly various AI-related features, but I also think that we should be able to better improve on the reliability and performance of the editor with lexical (the new one) vs. ckEditor (the current one). Lexical requires/allows us to own the whole stack for collaborative features, which is more overhead on our side, but many previous issues we’ve had with shared documents getting mysteriously corrupted should be much easier to prevent and debug now that we own the whole stack.
The new editor is currently restricted to users who are opted in to beta features. You can enable that setting under your account settings:
If you want to go back to using the previous default editor for now, you can opt out of experimental features by updating your account settings. You can also switch back to the previous editor on an ad-hoc basis when writing posts by using the editor type picker at the bottom of the post editor:
Any posts/comments/etc you wrote in the meantime will remain editable using whatever editor they were originally written in.
You can in theory convert posts from one editor type to the other by changing the editor type using the editor type picker, though there are some rough edges. Tables in particular will get lost when converting from the current editor to the new editor (though I expect we’ll fix this shortly); likely there are other gaps.
The new editor, in addition to the usual toolbars you get from either highlighting content or from clicking on the + button to the left of the editor, also features slash commands as shortcuts for inserting various kinds of custom elements or applying formatting operations:
It also supports some basic markdown auto-conversions, i.e. if you type [link anchor](https://www.linkurl.com) that will autoconvert to a link, and the same is true for basic formatting operations (bolding, italics, strikethrough). Most previous shortcuts remain functional: --- for line breaks, +++ for collapsible sections, etc.
Most collaborative editing features should continue to work, though there are some limitations around what types of suggested edits you can make—making suggested edits related to various custom elements isn’t yet supported.
We’ve broadly tried to maintain feature parity with other existing features (footnotes, collapsible sections, custom embeds, etc). There are some known gaps with table styling and nested elements in block quotes; if something else appears to be missing, that might be a bug or an oversight.
Please report any bugs or unexpected behavior to us, either here or on Intercom!
When applying bold or italic, then going back to Markdown, it becomes like this (I added escape characters in MD so the special characters would render when viewing this comment):
****bold****
*_italic_*
ETA: Apparently this is actually valid MD, just redundant. Is there a reason for it?
Curious whether y’all considered Tiptap as a base for the editor, and if so why you decided against it?
(Tiptap is what we use for Manifold/Manifund and there are definitely some warts—eg markdown not being supported out of the box, though recently I think that’s changed—but mostly I’ve liked it.)
We couldn’t find any implementation of anything like a suggested edits feature for Tiptap-based editors and didn’t want to be in the position of needing to implement it from scratch. Lexical was almost in that position, but ProtonMail’s docs (which I think maybe they acquired) are built on lexical, have a suggested edits feature, and are open source with a compatible license.
Also Tiptap was in the position of needing to support a lot of really old legacy browser behaviors, and iirc lexical made a pretty explicit design decision to avoid a lot of that for the sake of having saner internal & external APIs.
In a lot of ways, Tiptap probably would have been better—it’s certainly much more widely used, at least if you measure by “how many meaningfully-sized organizations use it in their stack” rather than “how many editors that end-users run into on the web are based on one vs. the other” (Meta uses lexical, so that’d be kinda skewed). But with the rapid improvements of LLMs for coding, I’m generally less afraid of future risks from lack of support.
LessWrong is rolling out a new (experimental) editor.
Why? Our primary motivation for implementing a new editor is to make it easier for us to quickly build new integrations and customizations, particularly various AI-related features, but I also think that we should be able to better improve on the reliability and performance of the editor with lexical (the new one) vs. ckEditor (the current one). Lexical requires/allows us to own the whole stack for collaborative features, which is more overhead on our side, but many previous issues we’ve had with shared documents getting mysteriously corrupted should be much easier to prevent and debug now that we own the whole stack.
The new editor is currently restricted to users who are opted in to beta features. You can enable that setting under your account settings:
If you want to go back to using the previous default editor for now, you can opt out of experimental features by updating your account settings. You can also switch back to the previous editor on an ad-hoc basis when writing posts by using the editor type picker at the bottom of the post editor:
Any posts/comments/etc you wrote in the meantime will remain editable using whatever editor they were originally written in.
You can in theory convert posts from one editor type to the other by changing the editor type using the editor type picker, though there are some rough edges. Tables in particular will get lost when converting from the current editor to the new editor (though I expect we’ll fix this shortly); likely there are other gaps.
The new editor, in addition to the usual toolbars you get from either highlighting content or from clicking on the
+button to the left of the editor, also features slash commands as shortcuts for inserting various kinds of custom elements or applying formatting operations:It also supports some basic markdown auto-conversions, i.e. if you type
[link anchor](https://www.linkurl.com)that will autoconvert to a link, and the same is true for basic formatting operations (bolding, italics, strikethrough). Most previous shortcuts remain functional:---for line breaks,+++for collapsible sections, etc.Most collaborative editing features should continue to work, though there are some limitations around what types of suggested edits you can make—making suggested edits related to various custom elements isn’t yet supported.
We’ve broadly tried to maintain feature parity with other existing features (footnotes, collapsible sections, custom embeds, etc). There are some known gaps with table styling and nested elements in block quotes; if something else appears to be missing, that might be a bug or an oversight.
Please report any bugs or unexpected behavior to us, either here or on Intercom!
When applying bold or italic, then going back to Markdown, it becomes like this (I added escape characters in MD so the special characters would render when viewing this comment):
****bold****
*_italic_*
ETA: Apparently this is actually valid MD, just redundant. Is there a reason for it?
Nope, I haven’t tested the conversion to markdown—will add it to the list of things to check, thank you!
Curious whether y’all considered Tiptap as a base for the editor, and if so why you decided against it?
(Tiptap is what we use for Manifold/Manifund and there are definitely some warts—eg markdown not being supported out of the box, though recently I think that’s changed—but mostly I’ve liked it.)
We couldn’t find any implementation of anything like a suggested edits feature for Tiptap-based editors and didn’t want to be in the position of needing to implement it from scratch. Lexical was almost in that position, but ProtonMail’s docs (which I think maybe they acquired) are built on lexical, have a suggested edits feature, and are open source with a compatible license.
Also Tiptap was in the position of needing to support a lot of really old legacy browser behaviors, and iirc lexical made a pretty explicit design decision to avoid a lot of that for the sake of having saner internal & external APIs.
In a lot of ways, Tiptap probably would have been better—it’s certainly much more widely used, at least if you measure by “how many meaningfully-sized organizations use it in their stack” rather than “how many editors that end-users run into on the web are based on one vs. the other” (Meta uses lexical, so that’d be kinda skewed). But with the rapid improvements of LLMs for coding, I’m generally less afraid of future risks from lack of support.