Better backtick behaviour #16756
Better backtick behaviour #16756
Conversation
| return result === nothing ? nothing : LaTeX(result) | ||
| withstream(stream) do | ||
| ticks = startswith(stream, r"^(`+)") | ||
| result = readuntil(stream, ticks) |
There was a problem hiding this comment.
I'm confused by this code. startswith doesn't seem to have any methods that take an IO argument, and even if it did it seems like you're passing a boolean value to readuntil
There was a problem hiding this comment.
The startswith and readuntil aren't from Base, they're different functions specific to the Base.Markdown module. It's definitely confusing and their names should probably be changed when #12740 gets done.
Markdown.startswith returns either nothing or the regex match, in this case the string of opening backticks. Markdown.readuntil then reads up until the matching closing backticks. If the do block returns nothing then withstream resets stream to where it was when entering the block.
|
ready to merge? |
|
My immediate reaction was that it's was kind-of-weird that this would be different to CommonMark, and I wondered whether counting odd-ness for different behavior is going to be surprising. However, I calmed down a little, though I'm still not completely convinced. (my 😕 stands; 😀 ) But I don't have a counter-proposal. |
|
For what it's worth: seems like a decent approach to me. |
|
I don't hate the idea of gradually formalizing a "Julia-flavored Markdown" since we're finding things we need that don't exist in established dialects. |
This extends the backtick syntax in the markdown parser to generalise the "one tick = code" and "two ticks = math" rule to "odd ticks = code" and "even ticks = math". Doing this regains the nesting behaviour of backticks and allows both inline code and math to contain arbitrary sequences of backticks so long as enough backticks are used to wrap the code/math.
|
Thanks for the feedback @hayd. I agree that we shouldn't break from CommonMark if possible, though in this case there doesn't seem to be any agreed upon syntax for inline maths as far as I can see in the spec. If anyone does come up with a good alternative to this then we can move to that when we find it. For the moment I'll rerun CI with an additional change (stripping leading and trailing whitespace in inline |
da2fcb6
to
1f72b74
Compare
|
My general thoughts on this is that we should follow CommonMark, but where it doesn't provide a way to do things (e.g. references, definition lists, inline math, math blocks, etc.), we should choose conventions for JuliaMark (or whatever we want to call it) that will render reasonably when interpreted by a standard CommonMark markdown implementation, but which we can interpret with additional meaning. Using even number of backticks for math fits that since it will be rendered as code by implementations that know nothing about the convention, which is a reasonable enough behavior. |
|
This also deviates a little from commonmark in that: is allowed. This surprised me, although most implementations seem to do that. To confirm, this change is just for inline code? (Not blocks?) In which case, big 👍 . |
|
The run-on behaviour has been around since Yes, it's just inline, not blocks. |
|
For blocks I think that opening with ````math` might be better. |
|
For display equations, we are using ````math Lines 389 to 394 in a65b334 |
This extends the backtick syntax in the markdown parser to generalise the "one tick = code" and "two ticks = math" rule to "odd number of ticks = code" and "even number of ticks = math".
Doing this regains the nesting behaviour of backticks and allows both inline code and math to contain arbitrary sequences of backticks so long as enough backticks are used to wrap the code/math.
(Running
genstdlib.jlpicked up an edgecase that wasn't being parsed correctly before this change.)