Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stable first cut of RTE #4734

Closed
lampholder opened this issue Aug 2, 2017 · 6 comments
Closed

Stable first cut of RTE #4734

lampholder opened this issue Aug 2, 2017 · 6 comments

Comments

@lampholder
Copy link
Member

lampholder commented Aug 2, 2017

We've done a lot of work on the RTE of late, and we want to get this in front of people in a way that:

  • realises the value of this work
  • doesn't introduce unreliable or unpredictable behaviour

Proposal

The most significant source of bad behaviour is converting back and forth between markdown and rich text content. There does not exist a reliable way to do this conversion. so the proposal is that we do not do this conversion.

The proposal is to maintain two separate versions of the composer, 'Rich Text' and 'Markdown'.

Both versions of the editor will have their own independent histories, and both will support quoting exactly as it is on /develop today, warts and all (a better quoting system comes from referencing quoted events directly, not from digesting historical messages into representative markdown).

  • the markdown composer will:
    • support sending either markdown formatted text or plain text
    • accept rich text pastes, but digest them into a plaintext representation (crucially it will not translate formatted text to a markdown representation)
  • the rich text composer will:
    • support sending rich text only
    • accept rich text pastes maintaining formatting

To reduce surprise when switching between editors, this setting will be on the user settings panel (we can leave a keyboard shortcut for power users).

When toggling, we should consider advising the user that:

  • any message they are currently composing will be lost
  • their Rich Text composer history won't be accessible from the Markdown editor, and vice versa
@ara4n
Copy link
Member

ara4n commented Aug 2, 2017

i think this may be a step backwards - i for one spend a lot of time toggling markdown on & off depending on what i'm writing. I think a simpler check would be to warn the user that they will lose their message when toggling it (if they are mid-writing a message).

I honestly don't think we need to agonise about the round-tripping at all; if weird things happen when you toggle, I don't think folks will be that surprised.

I'm much much more worried about the other flakinesses we've seen which impact normal typing (e.g. races between clipboard & typing, or bad interactions between pills & editing within the composer) rather than the edge case of toggling.....

@turt2live
Copy link
Member

I'm not sure I'd be a fan of having two different editors where the only noticed difference is how my selection gets pasted into Riot. To be honest, I didn't realize this was a feature until reading this proposal - I've always just toggled markdown on/off for whether or not I wanted my message to be parsed as markdown.

It appears as though disabling markdown also disables the rich text option - which seems like an unexpected side effect rather than a feature (despite it being a feature). Would a "Paste with formatting" (and maybe a partner "Paste without formatting") button achieve the same end goal? This would allow the markdown button to do just markdown, and the rich text on/off be handled by something else. I'd imagine a user setting to "default paste with[out] formatting" would come as a result of this as well.

@lampholder
Copy link
Member Author

lampholder commented Aug 4, 2017

I confess that I am struggling to reason sensibly about the composer, I think because there are so many orthogonal dimensions to the thing.

Fundamentally, we want something stable that we can release soon and continue to build upon.

Can we get here more quickly by making some broad descoping statements:

  • all pastes are plain text only
  • pills are not rehydrated out of markdown message history - it's just the plain text of the display name
  • switching between rich text/non rich text throws away the contents of the composer
  • pulling a rich text message from history when the composer is not in rich text mode just pulls the plain text version

@lampholder
Copy link
Member Author

lampholder commented Aug 4, 2017

It appears as though disabling markdown also disables the rich text option

Does it? I thought disabling markdown was the only way to enable rich text option? (On /develop)

This would allow the markdown button to do just markdown, and the rich text on/off be handled by something else.

I like the idea of markdown on/off and rich text on/off being decoupled, but I don't think it's possible to have both "on" simultaneously.

Would a "Paste with formatting" (and maybe a partner "Paste without formatting") button achieve the same end goal?

This might be a nice enhancement beyond "paste everything as plain text"

@turt2live
Copy link
Member

You're right, disabling markdown enables rich text, which is still counter-intuitive imo.

@ara4n
Copy link
Member

ara4n commented Jul 16, 2018

no need as of matrix-org/matrix-react-sdk#1890, hopefully :)

@ara4n ara4n closed this as completed Jul 16, 2018
@jryans jryans added the A-Pills label Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants