Escaping (double) backslashes in source.gfm

[cokelly]

Backlashes are no longer escaped in snippets in the latest Atom, including in safe mode.

For instance, if I place the following in snippets.cson:

".source.gfm":
    "TEST":
        prefix: "test"
        body: "\\centering\\noindent\\rule{0.75\\textwidth}{0.4mm}"

I get the following in the markdown file:

centeringnoindentrule{0.75textwidth}{0.4mm}

Whereas previously I would have got:

\centering\noindent\rule{0.75\textwidth}{0.4mm}

I am on Arch Linux, Atom version 0.192.0-9a0c3f9

[izuzak]

This looks like a duplicate of #127 (which was closed by the user). As mentioned in that issue, it's probable that this changed with #123, but I'm not sure if that was intended. /cc @soren-n @kevinsawicki

[cokelly]

Certainly looks like a duplicate of #127 alright. I note that when I try one or three backslashes on the example above, I don't get an escape. For instance, \\\textwidth is rendered as <tab>extwidth and \\\noindent is rendered as <line-break>oindent etc.

[izuzak]

Yeah, you need to use four backslashes currently: #127 (comment). Again, not sure if this is intended behavior or not.

[cokelly]

Sorry - I didn't spot that. Four backslashes works for me too!

[izuzak]

Thanks for confirming! Let's leave this open until @soren-n and @kevinsawicki let us know if these changes are intended or not -- just want to make sure. 👴 ✌️

[soren-n]

I think that four backslashes makes sense, however notationally inconvenient.

It has to do with the levels of interpretation a snippet goes through before it ends up in your text buffer:

1. The snippet is declared in a CSON file, the parsing of string elements in this format is "backslash sensitive" i.e. \n represents the newline character and a \ is represented as \.
2. The snippet then has to be parsed by the snippet body parser. The parser uses one \ to escape the following character, e.g. \ becomes .

So the process goes as follows:
\\ --CSON--> \ --BodyParser--> \

The reason two backslashes used to work, was because the snippet body parser never really handled escaped characters (the escape cases were handled explicitly rather than in a generic way) this was why we had bug #60.

The process could be made more notationally friendly if the snippets were stored in a custom format. Then we would have more control over how it is parsed, such as not interpreting backslashes before they are being fed to the body parser.

[50Wliu]

I agree with @soren-n here. If there was a way where backslashes wouldn't be escaped until they actually got parsed by the snippet parser, that would make things much clearer and prevent confusing this-should-work-but-it-doesn't bugs.

[izuzak]

Thanks for explaining, @soren-n -- that makes sense. If we're comfortable with this change -- we should update snippets in Atom-owned packages which use the old \\ way (e.g. this file uses it a couple of times). @kevinsawicki If that sounds good to you, I can help with that. I also wish there was an easy way to find such snippets in user packages as well so that we can open pull requests to update them. 💭

[davidaugustocrawley]

Its a little awkward for making snippets for latex.
'.source.gfm':
'aligned':
'prefix': 'lx'
'body': '''$$\n\\begin{aligned}\n\\\\\n\\\\\n\\\\\n\\end{aligned}\n$$'''