Andrea Censi wrote:
> On 1/8/07, Jacob Rus <[EMAIL PROTECTED]> 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
_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss
