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

Escaping issues #434

Open
aidantwoods opened this issue Oct 1, 2016 · 0 comments
Open

Escaping issues #434

aidantwoods opened this issue Oct 1, 2016 · 0 comments
Labels

Comments

@aidantwoods
Copy link
Collaborator

aidantwoods commented Oct 1, 2016

Test Data

I'm running the following test data through Parsedown:
screen shot 2016-10-01 at 19 16 34

The expected result is as follows:
screen shot 2016-10-01 at 19 08 18

However, this is the result I obtain from the parser:
screen shot 2016-10-01 at 19 24 01

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: \\\\\``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant