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

CommonMark simplifications #4404

Closed
1 task
MightyCreak opened this issue Jun 23, 2017 · 9 comments
Closed
1 task

CommonMark simplifications #4404

MightyCreak opened this issue Jun 23, 2017 · 9 comments
Labels
A-Composer O-Uncommon Most users are unlikely to come across this or unexpected workflow P4 [OBSOLETE LABEL] Interesting — Not yet scheduled, will accept patches S-Tolerable Low/no impact on users T-Enhancement

Comments

@MightyCreak
Copy link

MightyCreak commented Jun 23, 2017

I open this issue to discuss CommonMark simplifications.

CommonMark, a stricter implementation of Markdown, is a text format that is meant to give a way to write structured documents and be easy enough to parse it and generate a rich-text view (like with HTML). Riot uses CommonMark, but the users rarely writes essays in Riot, so some features from Riot could be removed or changed and give the user a more intuitive way of writing formatted texts.

  • List formatting: only use "-" and remove the characters "*" and "+" (see explanation)

Edit: use "CommonMark" instead of "Markdown"

@MightyCreak
Copy link
Author

MightyCreak commented Jun 23, 2017

List formatting: only use "-" and remove the characters "*" and "+"

To make a list, I would suggest to use only "-" and remove the characters "*" and "+".
The rational behind that is that the different characters was there because in a huge document it allows to use different symbols when you have nested lists, like that:

* item 1
  - subitem 1
    + subsubitem 1
    + subsubitem 2
  - subitem 2
* item 2

That is very useful.. in a document. But much less in a short text message.
But why keeping only "-" and not one of the other characters, you say? Simply because it often happens to start a message with "+" or "", for instance "" is often used in text message to say that you didn't write a word corrcetly.
*correctly
And "+" is often use in a text message when you just want to add a point to your previous text.
+it's really weird to use "+" as a list character, so it becomes more disturbing than anything.
And finally, the character "-" is faster to write on US keyboards (no shift key to press).

But keep in mind that removing "*" and "+" doesn't prevent from doing nested lists. It's the starting spaces that makes a subitem, so the example above would give the exact same result written like that:

* item 1
  * subitem 1
    * subsubitem 1
    * subsubitem 2
  * subitem 2
* item 2

@t3chguy
Copy link
Member

t3chguy commented Jun 23, 2017

We use CommonMark, see commonmark.org/help
its a strict specification of Markdown, its unlikely a switch to a custom flavour would be done as then things might get ambigious between clients, this way anyone can load in a CommonMark lib and have it work exactly the same

@MightyCreak
Copy link
Author

Hmmm... I see.
I could be interesting to make our own MessageMark that would be an even stricter markdown specification for messaging apps. But I guess Riot devs have other things to do.

Should I close this issue?

@MightyCreak MightyCreak changed the title Mardown simplifications CommonMark simplifications Jun 23, 2017
@uhoreg
Copy link
Member

uhoreg commented Jun 24, 2017

The proper fix is probably to get the new composer working properly for newbies, and then those who want markdown can use that if they want to.

@MightyCreak
Copy link
Author

It's not about newbie vs pro-user. It's about proposing the right tool for the right job. The point being that using different characters to make lists is completely overkill in the context of an instant messaging app.

I personally like using Markdown/CommonMark formatting for my messages, I don't especially want a composer where I would have to click on a button every time I want to format something. Slack don't provide any composer at all and there's no complaints so far, but they've stripped the unnecessary parts.

I don't say Riot has to do exactly the same (for instance users can't make lists in Slack, and that's a shame), but it's not a reason to go on the opposite side of the spectrum.

@turt2live
Copy link
Member

ftr, I quite like the various options to form a list. I've used differing symbols to indicate different meaning to some plain text readers, and I normally default to asterisks myself.

@lampholder
Copy link
Member

I like simplicity, but I haven't ever been tripped up by the multiple-bullet options.

Not least because the *correction convention doesn't actually trigger a bullet (you'd have to put a space between your asterisk and your typo-fix).

I suggest we leave this here and if people do find themselves tripping up over the complexity they can upvote.

@MightyCreak
Copy link
Author

You're right, *correction doesn't trigger a formatting. Weird... I was sure I had this problem.
But there is still the '+ something' that triggers a list, which is unexpected.

I've encountered this issue a couple of time, but I've also seen some less-techy friends having the issue as well, but not understanding why it became that.

That being said.. If we had message edition, that issue would not really be an issue.

@lampholder lampholder added type:rte P4 [OBSOLETE LABEL] Interesting — Not yet scheduled, will accept patches labels Jul 21, 2017
@MadLittleMods MadLittleMods added S-Tolerable Low/no impact on users O-Uncommon Most users are unlikely to come across this or unexpected workflow labels Aug 24, 2021
@t3chguy
Copy link
Member

t3chguy commented May 7, 2022

Closing in favour of element-hq/element-meta#330 as the more general markdown dialect discussion

@t3chguy t3chguy closed this as completed May 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Composer O-Uncommon Most users are unlikely to come across this or unexpected workflow P4 [OBSOLETE LABEL] Interesting — Not yet scheduled, will accept patches S-Tolerable Low/no impact on users T-Enhancement
Projects
None yet
Development

No branches or pull requests

8 participants