Discourse and CommonMark


(Chris Saenz) #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?


(Jens Maier) #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).


(Kane York) #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.


(Jens Maier) #4

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


(Kane York) #5

May 28 2014

The current version reads:

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

(Jens Maier) #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.


(Jeff Atwood) #7

Any comment on this @sam?


(Sam Saffron) #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.


(Jake Shadle) #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.


(Erlend Sogge Heggen) #10

I believe it’s scheduled for v1.6:


(Jake Shadle) #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?


(Erlend Sogge Heggen) #12

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


(Jake Shadle) #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:


(William Di Luigi) #14

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


(Rafael dos Santos Silva) #15

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


(Dave McClure) #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…


Editing: An insert table option
(Jeff Atwood) #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.


(Burke) #18

Too big of a project for GSoC 2017?


(Jeff Atwood) #19

Vastly too big and complex.