You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running the following test data through Parsedown:
The expected result is as follows:
However, this is the result I obtain from the parser:
Issues within inline code
Ignoring the cases where == syntax (<mark> tags) are not parsed (I don't think that's a feature of Parsedown outright), it looks like the parser isn't honouring backtick escapes within code.
To keep it usability friendly, I'd recommend only treating backticks matching the following as non-literal:
Regex: (?:(?<![\\]|[`])|(?<![\\])(?:[\\]{2})+)([`])
And only treating backslashes matching the following as literal (when acting directly on the contents of inline code – so that $ would implicitly match an `)
Regex: ([\\])(?=[\\]*+[^`$])
Those rules should allow all characters to be literal, except for an `, or an \ if and only if that \ is part of an escape sequence of one or more \ followed immediately by the end of the string, or an ```. In the case of a such sequence of backslashes being found within the contents of inline code, treat any backslash as an escape character for the character immediately after it. E.g. so that \\\\\` is interpreted as the literal string `` \` ``
Issues elsewhere
Another thing to note, Parsedown doesn't appear to be honouring the line
testing starting *italic then `code which should be italic with a literal * and then end code` then end italic* back to normal
Which should render as follows (I'll let GitHub do this one)
testing starting italic then code which should be italic with a literal * and then end code then end italic back to normal
However, it looks like that because of the way in which Parsedown is evaluating the string, the unescaped, but still literal * within inline code is being treated as the ending of the italic element, which is started prior to the inline code.
Source
(almost) source of the test here, but remove escapes where lines are " ``` "
``somecode``
```some more code```
inline writing `code` and then some more `code with an escaped \` to test `
``inline code sometimes might start with \`\`, and have an unescaped ` nested inside``
\```
testing *asterisks*
\```
`testing *asterisks*`
testing ==`highlighted code`==
testing ~~`stricken code`~~
testing starting *italic then `code which should be italic with a literal * and then end code` then end italic* back to normal
testing ==`highlighted code with if(a == b) echo "yes"`==
`testing ==doubleequals==`
`unescaped escapes \ should render`
`escaped escapes \\ should render both escapes`
`triple escapes \\\ should render all three etc...`
`escaped escapes \\< \\* preceeding special chars should also render all characters`
`we should be able to escape a \`, we should also be able to end inline code by escaping an escape \\` which preceeds a `
`lets test some backticks: escaped backtick: \`; escaped escape, then escaped back tick: \\\`; escaped escape, then escaped escape, then escaped backtick: \\\\\``
The text was updated successfully, but these errors were encountered:
Test Data
I'm running the following test data through Parsedown:
The expected result is as follows:
However, this is the result I obtain from the parser:
Issues within inline code
Ignoring the cases where
==
syntax (<mark>
tags) are not parsed (I don't think that's a feature of Parsedown outright), it looks like the parser isn't honouring backtick escapes within code.To keep it usability friendly, I'd recommend only treating backticks matching the following as non-literal:
Regex:
(?:(?<![\\]|[`])|(?<![\\])(?:[\\]{2})+)([`])
And only treating backslashes matching the following as literal (when acting directly on the contents of inline code – so that
$
would implicitly match an`
)Regex:
([\\])(?=[\\]*+[^`$])
Those rules should allow all characters to be literal, except for an
`
, or an\
if and only if that\
is part of an escape sequence of one or more\
followed immediately by the end of the string, or an ```. In the case of a such sequence of backslashes being found within the contents of inline code, treat any backslash as an escape character for the character immediately after it. E.g. so that\\\\\`
is interpreted as the literal string `` \` ``Issues elsewhere
Another thing to note, Parsedown doesn't appear to be honouring the line
Which should render as follows (I'll let GitHub do this one)
testing starting italic then
code which should be italic with a literal * and then end code
then end italic back to normalHowever, it looks like that because of the way in which Parsedown is evaluating the string, the unescaped, but still literal
*
within inline code is being treated as the ending of the italic element, which is started prior to the inline code.Source
(almost) source of the test here, but remove escapes where lines are " ``` "
The text was updated successfully, but these errors were encountered: