Noparse

[Nick Evan]

Is there a way to stop a piece of text from getting parsed? With BBCode we used to have [noparse] tags?

[~s.o.s~]

Depends on what you plan on "escaping" but pre-pending something with backslash (\) usually does the trick given that we are dealing with a Markdown variant here.

For e.g.

`my_var` => my_var but
\`my_var\` => `my_var`

EDIT: Highlighting is a bit broken when it comes to escaping stuff as you can see if you try to edit this post so try not to be confused by the in-consistent coloring when escaping.

[~s.o.s~]

@Nick: Did that work or are you still facing issues?

@Dani: Won't it be a good idea to add the escaping related help topic to the "Formatting help" page under "Advanced"?

[deceptikon]

I'm not sure the backslash is an "official" solution. Unfortunately I'm not in a place where I can peruse the code at the moment, but I don't recall any provisions in the parser for such a thing, so it may simply be an unintended feature that could potentially go away after upgrades.

If I may ask, what's the use case for no parse here? Is it still the auto-linkification of URLs or something different?

I'm not sure the backslash is an "official" solution.

So what is?

I remember the [noparse] - v. useful. Use cases - backticks inside SQL? Not an issue if you put the statement into code tag, but what if you just want to show this:

You should try `backticking` like this.

Used backslashes - worked. Otherwise it's the old inline code. ANd if you try putting backslahes inside inline code... well that's just asking for trouble isn't it?

Place your table in a backtick, like this: table (it just makes them invisible)

[deceptikon]

As mentioned, I'm not in a position to check the code presently (but I will be come Monday). If there's not any blessed method in our current version of extended Markdown to disable parsing of a "tag", I can work on adding that capability.

[Dani]

I think I'm still confused why any additional functionality is required. How many use cases are necessary in which one would need to add backticks to inline code in such a case where using the backslash to escape the backtick is too inconvenient?

Additionally, Markdown has been designed in such a way as that the combination of characters required to trigger something are obscure enough that if you're accidentally parsing something, odds are you're not using code tags when you should be.

[~s.o.s~]

I'm at a bit of a loss to understand why is a strong justification required to use backslash when escaping stuff in Markdown. Backslash used for escaping is a part of the Markdown specification and hence was quoted as a solution by me to Niek's query.

If there's not any blessed method in our current version of extended Markdown to disable parsing of a "tag", I can work on adding that capability

If you folks are using a Markdown parser, there is no need of adding something. A parser supporting Markdown knows how to do this. Of course, the home grown modified Markdown parser for the client side rendering might be a bit problematic.

I think I'm still confused why any additional functionality is required. How many use cases are necessary in which one would need to add backticks to inline code in such a case where using the backslash to escape the backtick is too inconvenient?

It just isn't about backticks. Pretty much any special character which starts Markdown parsing needs to be escaped if you want a literal for that character; this includes braces, brackets, underscores etc. Reference: http://daringfireball.net/projects/markdown/syntax#backslash

[Dani]

Pretty much any special character which starts Markdown parsing needs to be escaped if you want a literal for that character; this includes braces, brackets, underscores etc.

I understand that. However, what I mean is that, in 99.999999999% of cases, if you're using braces and brackets in such a way as to trigger Markdown to parse something, you should be using code tags, in which case no escaping should be necessary.

[~s.o.s~]

However, what I mean is that, in 99.999999999% of cases

Right, my point is that let's just leave that backslash support around for those 0.000000001% of the cases instead of simply not supporting them.

[Dani]

That's what we do.

[~s.o.s~]

That reply was triggered by the following posted by Deceptikon:

I'm not sure the backslash is an "official" solution. Unfortunately I'm not in a place where I can peruse the code at the moment, but I don't recall any provisions in the parser for such a thing, so it may simply be an unintended feature that could potentially go away after upgrade

If it is here to stay, all well and good.

[Dani]

As he mentioned, he doesn't currently have access to the code so I guess was shooting from the hip on that one.

So from what I read, Deceptikon needs to confirm the backslash for escaping purposes (for whatever reason the poster feels s/he needs to escape - not our job to second guess the needs of the poster, right?) and then if this is confirmed, it will be added to the formatting help. That right?

[deceptikon]

So from what I read, Deceptikon needs to confirm the backslash for escaping purposes

Yup.

not our job to second guess the needs of the poster, right?

Actually, it is our job as developers. ;) Sometimes there's a way to do what's wanted without adding a new feature. Sometimes a new feature is needed but what the poster requests isn't an optimal solution to the problem. By "second guesing", we can verify what the real needs of the poster are and act accordingly.

In particular, while I'm definitely going to see if the backslash is an explicitly allowed escaping mechanism and not just something that falls out of the parser, I have no intention of adding a new feature until I'm confident that the new feature is truly needed and how best to implement it given use cases (that both I and Dani have asked for in this thread...still waiting).

[Dani]

for whatever reason the poster feels s/he needs to escape - not our job to second guess the needs of the poster, right?)

Goodness gracious! I could only imagine what would happen if we took all the "needs" of every user into consideration without asking them why it's so important they have it or how often they would use the feature. Every possible combination that any individual person can think of using once in their lifetime all garbled up into a single page.

It was not my intention to suggest all possibilities should be catered for - just that in this particular instance, one can't conclude that certain markdown codes would only occur inside code tags. Having re-read my post, I see how it must have sounded. I think the sql use case was a fair point (SOS and myself).

[deceptikon]

I just checked the code, and backslashes are indeed an explicit escape character, so I guess there's no problem openly recommending their use for the rare cases where you don't want Markdown tags to be processed.

I think the sql use case was a fair point (SOS and myself).

My bad, I totally missed that example.