BTW I miss the old setup where I could change the editor on the fly to switch between markdown and rich text. For example one problem now is that I don’t know how to markup LLM output in the markdown editor, but the rich text editor does not allow me to paste in markdown content. Another is that I can no longer write in markdown then switch to rich text as a way to preview what I wrote.
Yep, my current plan is to completely fade out the Markdown editor (it only historically existed because mobile editor support has been lacking).
And then I want to just have a “import markdown” /-command, which you can use to import Markdown, wherever you like, plus an “copy as markdown” selection-menu item so you can copy any text as markdown.
I think that will just be the less error-prone system.
Yes. The markdown editor has bugs with converting to/from other editors (e.g. footnotes get fucked) that it is a better idea to ban converting altogether than having no warnings. But I also want to complain about how many minor usability issues the new Lexical editor has. It felt like a mistake shoving the Lexical editor to everyone’s face. I just counted 6 annoyances/small bugs I reported via Intercom and 3 more invariouscomments. Kudos to the team for fixing most bugs super quickly, but the number of bugs seem higher than you would want for a mass rollout where you changed the default and removed the option to switch back (to ckeditor, or to markdown within the box).
This is pretty acceptable, if paste-from and copy-as work well. Gdocs does this to an acceptable degree—there’s something janky about images sometimes.
I’d like it if there were feature parity (e.g. equivalent footnote behaviour, image captions in markdown, LM content tags, not sure what else but e.g. your fun new widget inlines) but I very much see why that could be low on the priority list.
Last we spoke you were talking about API or command line integration which would in principle allow a very wide range of editing/importing workflows, at least for power users.
Last we spoke you were talking about API or command line integration which would in principle allow a very wide range of editing/importing workflows, at least for power users.
That is now there! It’s what powers our LLM integrations:
BTW I miss the old setup where I could change the editor on the fly to switch between markdown and rich text. For example one problem now is that I don’t know how to markup LLM output in the markdown editor, but the rich text editor does not allow me to paste in markdown content. Another is that I can no longer write in markdown then switch to rich text as a way to preview what I wrote.
Yep, my current plan is to completely fade out the Markdown editor (it only historically existed because mobile editor support has been lacking).
And then I want to just have a “import markdown” /-command, which you can use to import Markdown, wherever you like, plus an “copy as markdown” selection-menu item so you can copy any text as markdown.
I think that will just be the less error-prone system.
Yes. The markdown editor has bugs with converting to/from other editors (e.g. footnotes get fucked) that it is a better idea to ban converting altogether than having no warnings. But I also want to complain about how many minor usability issues the new Lexical editor has. It felt like a mistake shoving the Lexical editor to everyone’s face. I just counted 6 annoyances/small bugs I reported via Intercom and 3 more in various comments. Kudos to the team for fixing most bugs super quickly, but the number of bugs seem higher than you would want for a mass rollout where you changed the default and removed the option to switch back (to ckeditor, or to markdown within the box).
This is pretty acceptable, if paste-from and copy-as work well. Gdocs does this to an acceptable degree—there’s something janky about images sometimes.
I’d like it if there were feature parity (e.g. equivalent footnote behaviour, image captions in markdown, LM content tags, not sure what else but e.g. your fun new widget inlines) but I very much see why that could be low on the priority list.
Last we spoke you were talking about API or command line integration which would in principle allow a very wide range of editing/importing workflows, at least for power users.
That is now there! It’s what powers our LLM integrations: