Backslash escapes (was: Revised 2005 proposal for meta-data)

[Michel Fortin]

Le 2007-01-01 à 15:25, Andrea Censi a écrit :


>> [1] Even further, you could allow non-punctuation to be escaped.

>

> In a sense, this is the most consinstent way of escaping.


Why so? Either you have a fixed list of what you can escape and what  
you cannot, either you can escape everything. Both cases seems pretty  
consistent to me.

As an aside, this makes me think that there's a small integration  
problem when using Markdown with SmartyPants that makes it necessary  
in many cases to double-escape a litteral character so that  
SmartyPants ignores it:

\\\\\ two backslashes
\\\`` two backticks
\\--  two hyphens
\\... three dots

Maybe Markdown should convert escaped characters to their numerical  
entity equivalent (like SmartyPants does) so that the escape  
propagates to SmartyPants too without requiring two more backslashes.



> If the rule holds for every context in the document, than the

> algorithm for interpreting the document is very very simple:

> 1 - first pass: substitute every escaped sequence with placeholders

> representing the literal

> 2 - do regexp/parsing ignoring the escapes

> 3 - substitute the placeholders


Do you expect that rule to hold for code blocks, code spans, HTML  
blocks and the content of attributes inside inline HTML tags? There's  
a reason you don't need escapes in theses modes: it makes editing  
easier as you can copy paste parts of code or HTML markup without  
having to bother about the content at all.



> The summary of all this discussion is:

> 1) Everywhere all characters can be escaped (except in code blocks)

>   a)  "\ " represents a non-breaking space


Personally, I strongly disagree with overloading the escape mechanism  
to make it replace the following character by something else. I don't  
think Markdown needs a special syntax for non-breaking spaces.


>   b)  \<newline> represents a linebreak


I can't see why this would be better than what we have now. In fact I  
think it's worse as it'll clutter the text version of the document  
unnecessarily; the current double-space syntax means that the  
Markdown-formatted text looks fine by itself, something which is a  
core goal for Markdown.


> 2) Inside "quoted values", you MUST escape `"`

> 3) Inside 'quoted values', you MUST escape `'`


But what happens if you don't? If you want to go deep in the corner- 
cases of the syntax I think it'd be more useful to explain what  
parsers have to do when they encounter that rather than tell the  
author what not to write.



> I would tend to drop the special case

>> [text](url "title"with"quotes")

> as it is ambiguous.


Drop it and replace it with what output? I agree that it has some  
ambiguities, but it's not that bad really, especially when parsing  
with regular expressions. I do have a worry about this and it has to  
do with extending what can be expressed in the parenthesis, but  
that's not a big worry for me and I don't find the current syntax so  
much ambiguous.



> The first pass of processing the document simply becomes:

>

>     until eof

>        c = getc

>        if c == '\'

>            push literal(getc)

>        else if c == backtick `

>            count the number of backticks

>            possibly, eat one space

>            threat as literals everything until closing backtics

>        else

>           push literal(getc)

>       end

>    end


Something that sounds odd to me is that you're doing this as the  
first pass of the whole document, yet you don't take into account  
HTML blocks, code blocks and inline HTML tags, but you've thought of  
code spans. It'll have to get much more complicated than that if you  
want to handle escapes as a first pass.

Why do you want to proceed escapes first anyway?


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/