Skip to content

Conversation

facelessuser
Copy link
Collaborator

@facelessuser facelessuser commented Jan 20, 2017

This aims to have inline code escaping act more as one would expect in relation to how escaping is handled elsewhere. The best way to explain is by referencing the tests and babelmark https://johnmacfarlane.net/babelmark2/?text=%5C%5C%60code%60. Python Markdown is 1 of 3 who handle code escaping in (what I view) a non intuitive way. My personal belief is this buggy logic. So hopefully this pull will be accepted.

All we are doing is processing the escapes specifically related to code before we handle code.

Now, I realize the old tests were testing for this logic, and I understand why it was easiest to implement it as it was. If the old logic is preferred, I will need to make one more pull to make tables expect code escaping as it currently is. It should be a very easy pull, but I am hoping that this pull would be favored over such actions.

This aims to escape code in a more expected fashion.   This handles
when backticks are escaped and when the escapes before backticks are
escaped.
@facelessuser
Copy link
Collaborator Author

Didn't expect it was going to show the Merge remote-tracking branch. Well, if the idea behind this is accepted I can rebase.

@@ -1,3 +1,4 @@
\\`This should not be in code.\\`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, that makes no sense to me. Seems appropriate to change it. Unfortunately, the old commit message is less that helpful and it references an old issue tracker which is no longer online. This is why I like commit messages that stand on their own. But I digress...

This change might break some peoples' pages, but I'm okay with that as it is clearly an unexpected behavior and should be considered a bug.

@waylan
Copy link
Member

waylan commented Jan 20, 2017

https://johnmacfarlane.net/babelmark2/?text=%5C%5C%60code%60. Python Markdown is 1 of 3 who handle code escaping in (what I view) a non intuitive way.

Hmm, that seems to be a weird bug which was introduced in Markdown.pl 1.0.2b8 and was apparently faithfully copied in Python-Markdown and showdown. I think this can clearly be called a bug and changed.

@facelessuser
Copy link
Collaborator Author

facelessuser commented Jan 20, 2017

Hmm, that seems to be a weird bug which was introduced in Markdown.pl 1.0.2b8 and was apparently faithfully copied in Python-Markdown and showdown. I think this can clearly be called a bug and changed.

Great! I found it odd too. And since it was found in Markdown.pl as well, I wasn't sure how close to that we wanted to adhere to.

Is the remote-tracking commit an issue? I picked it up when I re-synced my fork (was trying to avoid re-forking).

@waylan
Copy link
Member

waylan commented Jan 20, 2017

Is the remote-tracking commit an issue?

Don't work about it. I'll do a "squash and merge" so it won't show up in the final commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants