Discourse and CommonMark

Feature
1

Continuing the discussion from Discourse doesn’t follow the CommonMark spec for HTML 

 tags inside code spans



I’ve wondered about this for awhile now. They aren’t that far off, but there are differences I know that will break some of my posts.


What happens to older posts if/when the Markdown interpreter changes; will we get a choice of interpreters to use, or just have to fix whatever breaks by hand? ie write it to the tighter spec now and avoid future issues?


Also, where is this on the roadmap?
1 Like
2

At first, nothing at all. Discourse runs the raw post content through its Markdown parser only when the post is saved, not when it is read.

This “cooked” post text remains untouched unless the post is edited, an admin (or mod?) clicks a special button (which affects that post only) or the server admin runs rake posts:rebake (which would rebake all posts in the forum).

3 Likes
3

Actually, the BAKED_VERSION variable would be incremented if a major change happened, which triggers a background task to, every hour? or so, rebake 100 posts that are currently on the old version.

1 Like
4

Oh, was this a recent addition? I thought I had read all the codepaths involved with (re)baking posts.

5

May 28 2014

https://github.com/discourse/discourse/commit/f6753d3d4642da5166d7466d53d707b89b6ed90b

The current version reads:

    Post.where('baked_version IS NULL OR baked_version < ?', BAKED_VERSION)
6

I see. Guess I should schedule an appointment with my eye doctor, seems I’m due for another diopter or two. :neutral_face:

Anyways, this seems crufty since the idea of version-dependent rebaking clashes a bit with the existance of different cook_methods.

2 Likes
7

Any comment on this @sam?

8

If we need to support more baking methods we are going to have to add a column on the posts table, I still thing version is correct there.

9

Is there any idea of when CommonMark support will be added?

I only bring this up because our users are still incapable of writing proper lists, which CommonMark seems to handle gracefully without a hard requirement on a line break between a paragraph and a list for it to be rendered as the user intends it to be.

Obviously this is a small issue in the grand scheme of things, but I imagine our forum is not the only one where this is the #1 most common mistake made when writing posts.

10

I believe it’s scheduled for v1.6:

2 Likes
11

Ahh ok, thanks for the link, that didn’t show up in my search. :wink:

However, it also says

which sounds like maybe it is actually after 1.6?

12

It’s prep work for the task that I linked to above, which is part of the same release :wink:

13

Ok, confusing, but I get it now, thanks! :slight_smile:

As you might be able to tell, I am really tired of this particular mistake so will be very happy when I can stop editing everyone’s posts to correct it. :smiley:

1 Like
14

I’m on discourse v1.7.0.beta2 +49 and I still see weird Markdown behavior. Has discourse switched to CommonMark yet?

15

Not yet. A lot of ground work for that was done on 1.6, tough.

4 Likes
16

Curious if there is any notion of when this might happen at this point…

I see that this is not on the 1.8 Release plan.

And that the the to-do list for CommonMark v1.0 is not draining too quickly.

Is CommonMark 1.0 considered a prerequisite for the transition? Or is it more about the stability of markdown-it API?

This is not a “where the !&*# is my CommonMark?” question. I’m just curious to understand what the current thinking is…

3 Likes
17

It is taking longer than expected, is all. I would be shocked if we do not get to this by sometime in 2018 thoigh.

2 Likes
18

Too big of a project for GSoC 2017?

1 Like
19

Vastly too big and complex.

5 Likes