[ANN] vfmd

[Roopesh Chander]

Alan,

Thanks a lot for your compliment.

Thomas,


> Have a look at http://kramdown.rubyforge.org/syntax.html for the

> specification of the syntax used by kramdown (note that this is a

> specification targeted at end users).


When I said "define [the syntax] unambiguously", I meant stuff like the
Markdown Extra spec [1] and peg-markdown's PEG file [2], which are targeted
at Markdown implementers (hence absolutely unambiguous) rather than
document writers (and so can have some ambiguity). Sorry about the
confusion.

[1]: http://michelf.ca/specs/markdown-extra/
[2]: https://raw.github.com/jgm/peg-markdown/master/markdown_parser.leg

Michel,

Thanks for taking a look at the spec. I've spent about 3 months on this
spec so far. For about a month before that, I had been thinking in the
background on how to write such a spec - maybe that counts as well.


> > A U+0009 (TAB) character in the input shall be treated as four

consecutive U+0020 (SPACE) characters.

>

> No. That's often not the case. If I write "*" followed by tab to begin a

line,

> that tab represents three spaces, not four. The number of spaces

represented

> by a tab is 4-(column_number modulo 4). But you probably knew that. ;-)


In vfmd, a TAB character is always 4 spaces. It's not like pressing TAB in
MS Word. For the same reason, from a user perspective, it's better to use
spaces instead of TABs to separate the list bullet char (`*`) from the list
item.


> About paragraphs:

>

> > 10. If none of the above conditions apply, then the block-element start

line marks

> > the start of a block-element of type paragraph.

> >

> > In order to find the block-element end line, we need to make use of a

HTML parser. [...]

>

> Oh oh... have you thought about code spans?


Good catch. Have filed an issue: https://github.com/vfmd/vfmd-spec/issues/1

I think it's a good idea to track problems found using GitHub issues
instead of mails - it's easier that way to (1) stay focused on the issue
and (2) locate the discussion in the future.


> I don't have more time to read the rest of your spec right now. But I

like the way it goes.

> I'll post more comments later.


I understand. Looking forward for your comments.

Thanks,
roop.


On Thu, Sep 26, 2013 at 11:44 PM, Michel Fortin <michel.fortin at michelf.ca>wrote:


> Le 26-sept.-2013 à 12:17, Roopesh Chander <roop at forwardbias.in> a écrit :

>

> > I'm pleased to announce the vfmd project to you all.

> >

> > vfmd is a variant of Markdown with a well-defined specification. The spec

> > is ready - I'm working on a testsuite at present and intend to start

> making

> > a working implementation after that.

> >

> > http://vfmd.github.io/

> >

> > I'm looking forward to knowing what you think. I'd especially like to

> hear

> > from Michel Fortin and John MacFarlane, who have tried to define the

> > Markdown syntax unambiguously in a spec or grammar before.

>

>

> Great. You've written a parser in prose. I'm impressed that you managed to

> have captured a lot of subtleties of the language within a formal spec.

> Seriously, how much time did you put into that?

>

> Ok, commenting as I read <http://vfmd.github.io/vfmd-spec/specification/>:

>

> > A U+0009 (TAB) character in the input shall be treated as four

> consecutive U+0020 (SPACE) characters.

>

> No. That's often not the case. If I write "*" followed by tab to begin a

> line, that tab represents three spaces, not four. The number of spaces

> represented by a tab is 4-(column_number modulo 4). But you probably knew

> that. ;-)

>

> About paragraphs:

>

> > 10. If none of the above conditions apply, then the block-element start

> line marks the start of a block-element of type paragraph.

> >

>

> >     In order to find the block-element end line, we need to make use of

> a HTML parser. [...]

>

> Oh oh... have you thought about code spans? If I write something like this:

>

>         This is `<pre>`.

>

>         Now the end tag: `</pre>`.

>

> with your block-level algorithm that does not take code spans into

> account, the HTML parser would make the above a single paragraph instead of

> two. The same could happen if you had tag-like things in the tile of a

> link, or with partial tags:

>

>         This is `<sp`.

>

>         Now ending the tag: `an>`.

>

> Or a comment.

>

> You could either instruct the HTML parser to ignore span-level tags while

> you're trying to delimit blocks, or you need the parser to be aware of

> span-level Markdown syntax (basically parsing span-level syntax at the same

> time you're delimiting your paragraphs).

>

> ... or you could try to be less clever and ask the user to start the

> paragraph with a block-level tag if he wants to use block-level HTML

> elements (like Markdown.pl and PHP Markdown do).

>

>  - - -

>

> I don't have more time to read the rest of your spec right now. But I like

> the way it goes. I'll post more comments later.

>

>

> --

> Michel Fortin

> michel.fortin at michelf.ca

> http://michelf.ca

>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20130927/9dc715fa/attachment-0001.htm>