We’ve been using pagedown as our rich composer for years. Unfortunately, we’d outgrown it in a few ways:
It’s very hard to extend to add features.
It hasn’t been updated in years.
It had implementations of features we didn’t like or found buggy like undo/redo. We forked the editor and removed them but that just left us with a lot of dead code.
It had zero tests. Modifying it meant we could be taking a detour to regression town U.S.A.
We made the decision to rewrite our composer using Ember.js so it was more in line with the rest of our codebase and so that we could allow people to extend it more easily.
In our master branch, we have the first attempt at this re-write and we’d love your help to test it out. We’ve deployed it to Discourse Meta already, however it has not replaced the main posting composer yet. This is a major code change and we want to make sure it works well before replacing the main functionality of Discourse. Instead we’ve replaced the rich markdown editor everywhere except posting:
The user preferences page, for editing your About Me
The admin page for editing text content
Editing queued posts before approving them
Editing category templates
If you have admin access on your own Discourse on the master branch you can test #2-4 but if you’re just trying here on Meta, the best place is #1.
Please post any issues or feedback on the new composer. If we find it works well we’ll replace the main composer shortly.
Fun Developer Stats
The new editor has 118 integration tests, covering all of its functionality.
The new editor is less than 350 lines of code (including the handlebars markup). Pagedown is over 2,300 lines! We’re going to be deleting a lot of code.
The quote button should insert some example text, when nothing was selected. Yes, I know the current editor doesn’t do it either, but it should. All the other buttons do.
The buttons that insert list items should select only the “List item” text, not the bullet point or number.
It doesn’t work at all from what I am experiencing in testing it out via the user CP here at Meta. I clicked it, expecting a > to pop up. Outputs nothing.
Or, maybe that is intended? Tried it here in the composer drawer and it does the same behavior. Ehh. Disregard this if I’m not using it correctly.
Currently you need to select some text for it to work. It’s the only button that doesn’t insert an example text. As you’ve already noticed the “old” editor doesn’t do it either, but it would be great if it would.
I remember people used to complain a lot about the behavior of the bulleted and numbered list buttons – the expectation was that selecting 3 lines, and pressing the list button, would turn the selection into a 3 item list. Which seems reasonable.
I notice when I click on anything in the menu (bold or italics, for example) in the editor, the cursor jumps to the bottom, no matter where the cursor was or what text is selected when I do so. Otherwise it’s looking pretty good to me!
Will the new editor be very different from the old one? Will there be a need to (re)educate community members?
I mentioned StackEdit elsewhere on Meta but I didn’t know it could be a possible candidate to help Discourse’s own composer. Well, at least with minimal work to make it a drop-in solution.
I see what you mean - the emoji popup is indeed blurry. That is not related to the new editor specifically, also in the old composer the popup is now blurry.
It looks like the blurryness is caused by the transform CSS statement which is now used to position the element. In previous versions this was achieved by using a negative top and left for the popup positioning.
Would be great to preserve browser conventions, and ideally have shortcut keys that replicate those of very popular apps such as Gmail, Google Docs or MS Word. I’m referring in particular to:
Ctrl+L - I expect it to go to the browser’s address bar, but Discourse hijacks it to insert a link
Ctrl+K - I expect it to insert a link (as it does in Gmail, Google Docs and Word), but Discourse made it add backticks to the selected text (something I personally always do before and after typing that piece of code).
Can you temporarily allow images in the “About Me” editor? I would very much like to test and ensure that image insertion works properly in Safari (and ideally pasting images, but I’m not sure that is expected to work in Safari).
It’s not easy. The image uploading widget counts on the images being in a post in a topic. It’s probably easier to wait and test that functionality when the composer is replaced.
If you don’t notice any differences that’s probably a good thing! The goal was to re-write it, not to change it completely. I did fix some weird behaviors along the way such as multi-line select and clicking the list icons but that wasn’t the main goal for the first stage.