Backslash escapes

[Jacob Rus]

Andrea Censi wrote:

> On 1/8/07, Jacob Rus <jrus at hcs.harvard.edu> wrote:

>>> The problem I find with the current syntax is that I cannot *see*

>>> whether there is the line break.

>> Get a text editor which allows you to color that line break ;)

> 

> So I guess the problem is: how do I tell Textmate to highlight that? :-)


Well, that one is super simple.  Just use ctrl-shift-p to get the 
current scope on one of those double-spaces, and then add such a scope 
to your theme of choice.  The current scope for such things is 
meta.dummy.line-break, but that should probably be changed, as there are 
better scopes, for instance under punctuation.separator.  Also, the 
scope should end in .markdown, as all the other scopes in the grammar 
do.  I'm sure it's on Infininight's list of bad scopes to be fixed.  I 
should probably add such an item to the Cobalt theme, so that its users 
can see hard line breaks.


>> Incidentally, is anyone interested at all in discussions on any of the

>> following:

>>

>>    1. Footnotes

>>    2. Tables

> 

> [PHP Markdown][1] and [Maruku][2] implement [this additional

> syntax][3] that covers footnotes and tables.

> 

> [Multimarkdown][6] implements footnotes the same way, and its

> implementation of tables is a superset of [3].


Okay, but I dislike the choices made by all of those, and there was 
quite a good discussion on this list with several (IMO) better 
propositions a year or two ago.  Someone should read through those 
discussions and summarize the result (I will do this eventually but it 
might be a while).

As an aside, using numbered links isn't as readable as named links, and 
putting the references right after the paragraph with their definitions 
makes the sites they link to easier to find, without being to clogged, 
in my experience.


> Maruku will implement the [new meta-data proposal][4], once it is

> stabilized with discussion on this mailing list. Also PHP Markdown

> will implement something similar. The new syntax uses curly quotes.


I really don't like this metadata proposal at all, since it ties 
markdown down completely to html, which is in my opinion a terrible 
design choice.  Also, I thought it was kinda ugly.  On the other hand, 
if there was a generic extension mechanism, then such a function could 
be relatively easily added, hopefully.


> If Multimarkdown's syntax for tables is better specified, I'll

> implement it for Maruku too. (you can't really implement anything from

> just one example, and I don't want to copy bug-by-bug one

> implementation).


No, don't do that.  There were several other table proposals, some of 
which were quite nice.  It might even be possible to accept multiple 
syntaxes, if the aforementioned extension mechanism happened.


>> for adding things like TeX-formatted math,

> 

> [Pandoc][5] and [Multimarkdown][6] implement inline math.

> Maruku will probably implement Pandoc's threatment  of TeX blocks and

> TeX-style inline math: $\alpha$.


Yes, but I don't really like the way that they convert markdown to TeX 
in general, which is to basically layer some xslt on top of the existing 
regexp-ish heuristics.  This means that the result is not nearly as nice 
as if the markdown program itself converted markdown to TeX or rtf or 
whatever.  Anyway, I think that such features must be carefully done to 
minimize the impact on existing markdown documents, while staying as 
clean as possible, and also fitting with TeX and other conventions. 
These goals are often in opposition, so before such features become more 
widespread, their syntax and implementation should be discussed carefully.


>>    3. A more formalized extension mechanism

>>

>> The first two of those have lengthy archived discussions which could use

>> someone summarizing them for the rest of us.  I plan on taking that up

>> at some point in the nearish future if no one else will.  The last would

>> be really nice, for adding things like TeX-formatted math, or lilypond

>> formatted music, or alternate table syntaxes, or whatever else, for

>> people running into markdown's limitations and not wanting to just use

>> raw html.

> 

> Could you give us an example? what exactly is an "extension mechanism"?


Some clear syntax that specifies a name and then some stuff to be passed 
to that extension, like some math could be: `{$ x = y}`, and some music 
could be: `{lily c d e f g a b c}`, where `$` or `lily` in this case is 
the name of the extension.  I don't know exactly what the best way would 
be, but I think that's better than adding completely new syntax for each 
feature, which leads to a much more complex language than necessary.  If 
you look, every other markup language, from xml to TeX to rtf has such 
an extension mechanism, all relatively clean, and they allow many things 
that the original authors of the language didn't anticipate the need for.

Anyway, it would be nice to be able to make extensions for inserting all 
sorts of things, from tables and math to specially formatted paragraphs 
to who knows what.

----

Anyway, in the future, if markdown gets a real parser, it would be nice 
to be able to have tables, footnotes, block quotes, etc. work whether 
the output is rtf or LaTeX or html or, I dunno, opendoc or something. 
It should be quite possible to pass different output filters the parse 
tree for the document, and have them produce beautiful output of all 
types.  Also, a real parser would be super fast, implementable much more 
easily in every language, possibly up to including it in javascript 
which could be rendered in real time, etc.  There are all sorts of 
benefits, beyond merely clarifying edge cases and squashing bizarre bugs 
of the current implementation.  But someone has to take the time to 
actually write a formal grammar for a markdown derivative, making sure 
not to break to much, and to carefully construct it to be built on 
further in the future.

Allan Odgaard expressed quite a bit of interest in such a project, but 
he's on vacation, and will be working full steam on TextMate 2 when he 
gets back.  So I'm not sure whether he'll have time for a few months. 
Anyway, earlier discussion on such points on this list got a very stony 
reception, with all sorts of bizarre support for the weaker aspects of 
the current implementation, so I'm not really sure opening that can of 
worms again in this email is the greatest idea.  But with your 
enthusiasm for this ruby port, etc., maybe we can get some real 
discussion going again.

-Jacob