Re: list corner case

[EMAIL PROTECTED] wrote: if one can do all those things another way, then i wouldn't treat this as _any_ of them. just leave it as-is, so people get channeled into doing each of those things "correctly". [...] i think, in the long run, that makes it easier for people, because it demands that th

Re: Syntax Questions

Jurgens du Toit wrote: If you look at a formatter like tidy, it's got a lot of options where you can turn certain behaviour on and off, making it much more useable for a lot of people. Wouldn't it improve the usability of Markdown if these kind of options were present? No, it would be a compati

Re: Markdown Extra Spec: Parsing Section

Michel Fortin wrote: Le 2008-05-12 à 18:14, John MacFarlane a écrit : The PEG representation is concise, precise, and readable. Readable, hum... if I look at this rule from PEG Markdown: ListContinuationBlock = a:StartList ( BlankLines { if (strlen($$.contents.str) == 0)

Re: Markdown Extra Spec: Parsing Section

Michel Fortin wrote: Anyway, with the parsing model in three passes I'm currently defining it's pretty trivial to do correctly: the block elements pass extracts the text of the blockquote, leaving this to parse by the span element pass: what about this case? The span element pass would t

Re: Markdown Extra Spec: Parsing Section

Michel Fortin wrote: I've began writing the parsing section of the spec, and I though I'd let you know about where I'm heading with all this. Also, you're still going to have quite a few sticky edge cases with your current parsing model. What happens when we have a `<>`-delimited URL inside

Re: Markdown Extra Spec: Parsing Section

Michel Fortin wrote: I've began writing the parsing section of the spec, and I though I'd let you know about where I'm heading with all this. You should write it in something closer to a BNF-like format. The current version is about 10x more verbose than necessary, and it makes reading the s

Re: Markdown Extra Specification (First Draft)

Sherwood Botsford wrote: four things: 1. Sometimes the link is *(@*&^(^ long. So if I'm editing with vi, I have everything else in 60-70 column lines, then this great bloody honker. Vi can't handle line wrap? Why do you need to look at the end of the URL? Eg. the usual unix convention of \

Re: Markdown Extra Specification (First Draft)

Sherwood Botsford wrote: Not to worry. I wasn't expecting backward compatibility, so that [...] THAT said, however, maintaining perfect backward compatibility slows down progress. If this is your view, you shouldn't put "markdown" in the name. Implementation specs: The program should have

Re: forking Markdown.pl?

Tomas Doran wrote: John Gruber wrote: Tomas Doran wrote: I'm actively maintaining the CPAN modules Text::Markdown, and Text::MultiMarkdown, and longer term, I'd like these to become the canonical distribution. I despise what you've done with Text::Markdown, which is to more or less make it

Re: [ANNOUNCE] cmarkdown-0.3

John Gruber wrote: On Dec 14, Jacob Rus wrote: Just out of curiosity, what's the point? Performance, I would guess. Okay, but improved algorithm is the way to improved performance, not changing languages. Perl (or whatever language you like) is perfectly capable of a markdown at le

Re: [ANNOUNCE] cmarkdown-0.3

Enno "Gottox" Boland wrote: I wrote an markdown interpreter in C. It should support most of the features markdown.pl has (hopefully). Please report any bugs. Just out of curiosity, what's the point? -Jacob ___ Markdown-Discuss mailing list Markdown-

Re: ANN: python-markdown2 -- another Python implementation of Markdown

[EMAIL PROTECTED] wrote: for ch in '\\`*_{}[]()>#+-.!') Generator expressions were introduced in python 2.4 I believe. You'll want to add `[` and `]` on the inside of those parentheses, to make this a list comprehension instead, and things should then just work fine.

Re: Flat code block syntax

Bruce Phillips wrote: Though not visually appealing, are there any (technical) thoughts on backticks (which are currently used for )? `` "Hello, code!" `` I like this idea. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://

Re: Incremental parser

Michel Fortin wrote: Allan Odgaard a écrit : Michel Fortin wrote: [...] Take a look at this instead: int[1][2] one_by_two_array; Sure, a code block or span should be used here, but I think *requiring* the code block or span here in order to not screw up the end result isn't the right pa

Re: Incremental parser

Michel Fortin wrote: That's assuming you have a separate preview mode, are using a special preview stylesheet, and that you actually look at the preview before publishing. I would not expect Markdown's usability to depend on such a precise workflow. For instance, have you thought about the po

Re: Incremental parser

Michel Fortin wrote: I don't think syntax highlighting is an argument that should help decide what Markdown should do. It's not, really. But you claimed that it's worse for “readers and writers” and I was explaining why it's better for me, as a reader and writer. To solve your problem, I s

Re: Backtick Hickup

John MacFarlane wrote: If the suggestion is that the lexer is going to identify '**' as a "strong emphasis marker" and '*' as an "emphasis marker," prior to any parsing, I don't see how that's possible. Consider ***bold** in italics* ***italics* in bold** There's no way of knowing whet

Re: Incremental parser

Michel Fortin wrote: I disagree about it being better for readers and writers. To me a sole asterisk or underscore doesn't mean emphasis. If someone voluntarily writes only one asterisk in front of a word, he probably didn't mean "emphasis until the end of the paragraph" either. Well, this re

Re: Incremental parser

re's a tricky case here however: [foo][bar] isn't a link in Markdown unless "bar" is defined somewhere; if it isn't defined, it's plain text. As previously mentioned that's quite trivial to pick up after the document has been completely tokenized. -Jacob Rus ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

On 8/3/07, Michel Fortin <[EMAIL PROTECTED]> wrote: This is simply because code blocks and the content of a list item with block-level content are denoted by the same thing: four space of indentation. To be able to create list items with block-level Ah, you're right. So this isn't one of the n

Re: Bug: Code block after list

of a real grammar/parser. Unfortunately there has been stiff (not particularly logical IMO) resistance to formalizing markdown on this mailing list. -Jacob Rus ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlis

Re: Markdown generates invalid html for a list immediately followed by a quote

John Gruber wrote: That's what I'm thinking the output should be. I think there should be an official rule that all block-level constructs must be separated by a blank line. This sounds just terrible to me. I don't want to require huge numbers of blank lines whenever I want deeply nested list

Re: Markdown generates invalid html for a list immediately followed by a quote

Waylan Limberg wrote: For that matter, I believe python already is pretty strict about requiring the blank line between any block-level constructs. There may be an exception or two in a few minor edge cases, but that's it. I'd say python is ahead of the curve on this one. Wrong. Python complet

Re: Searchable archives of Markdown discussion list still available?

Fletcher T. Penney wrote: I was interested in going back to research past discussions on the list about possibilities for a syntax to add a class="foo" to div's and/or span's to Markdown text, but didn't have much luck. IIRC, the list never had a searchable web interface, but older posts were

Re: div & span support

Andrea Censi wrote: > On 3/5/07, Richard Taytor <[EMAIL PROTECTED]> wrote: >>> [John Fraser:] Being able to wrap Markdown text in divs and spans ... >> I find div and span tags quite useful. Here is an example of the syntax I'm >> presently using. >> >> [[ {#orchard} >> Contents of div here. And ~

Re: [ANN] Showdown -- A javascript port of Markdown

Ivan Sagalaev wrote: > Jacob Rus wrote: >> If this markdown parsing can be done in real time in javascript, we >> should also be able to extend this to do real-time syntax highlighting >> on the markdown entry box, or am I wrong? Because that would be >> extremely c

Re: [ANN] Showdown -- A javascript port of Markdown

John Fraser wrote: > I've just posted the first public version of Showdown, a full > javascript port of Markdown. It's 10KB and works in all major > browsers. Try out the sample app: > > [...] > Developers can use Showdown to: > > * Add in-browser

Re: Proposal for meta-data (third revision)

Andrea Censi wrote: > Changes were: > > * Changed the syntax for compatibility with a future extension mechanism. > > The first character in the curly braces must be a colon, optionally > followed by a space: I wasn't meaning to suggest before that {«extension-name» «content»} wa

Re: Backslash escapes

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

Re: Revised - Revised 2005 proposal for meta-data

eciable benefit. I have two arguments against it. The first is if such a form is used: 1. As soon as a word is used as a link, it's no longer possible to use that word surrounded by brackets. Now this may not come up too many times, but when it does, it'll be a pain for the author. Je

Re: Revised - Revised 2005 proposal for meta-data

Jelks Cabaniss wrote: > Jacob Rus wrote: >>> John Gruber wants to introduce the >>> [single braket] syntax as a shortcut for reference-style links in a >>> future version of Markdown.[^1] > >>> [^1]: That future is not so far away: the shortcut re

Re: Backslash escapes

Andrea Censi wrote: >>> b) \ 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 fin

Re: Revised - Revised 2005 proposal for meta-data

Michel Fortin wrote: > John Gruber wants to introduce the > [single braket] syntax as a shortcut for reference-style links in a > future version of Markdown.[^1] > > [^1]: That future is not so far away: the shortcut reference-style > link syntax is currently implemented in the latest 1.0.2

Re: spacing before list continuations

John MacFarlane wrote: > Is this a bug, or should the documentated syntax be revised? This more > relaxed behavior is nice in some cases, but it seems to cause problems > in others. For example, this ought to be a nested list followed by a > horizontal rule: I say it's a bug, because it leads to

Re: best way to use emphasis within code?

Andrea Censi wrote: > Just an idea that strucked me. > If we had a syntax for creating SPANSs, he could write: > > === > And now type this: {$ **mail -u _user_**}{in} and then type > {$ cd .. }{1} > > {1}: style=font-family:fixed > === -1 This is ugly as hell. _

Re: Maruku: a better Markdown interpreter for Ruby.

Jan Erik Moström wrote: > A question: am I correct when I guess that all implementations > use regexp to parse the text Yes > or is there some implementation > that do "real" parsing? No ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairli

Re: Block quotes with a blank line between them get merged

A. Pagaltzis wrote: Editors with smart autoindenting support generally make it *more* annoying to work with whitespace-only lines, not less. Which is a feature. I was actually referring to editors with smart syntax highlighting (and mostly tongue-in-cheek, as I don't mean to offend those who u

Re: Block quotes with a blank line between them get merged

Michel Fortin wrote: I'm not sure if John opposes the two blank lines rule or not; what I'm sure is that he opposes taking into account the invisible indentation of these blank lines into account. And I agree with that position. The current rule is that code blocks start with four spaces or on

Re: Block quotes with a blank line between them get merged

A. Pagaltzis wrote: * Jacob Rus <[EMAIL PROTECTED]> [2006-10-19 22:30]: Can it be explained again why we need to have this explicit character at the beginning of lines? Is there some particular case of block quotes for which markdown isn't perfectly sufficient right now? This seems

Re: Block quotes with a blank line between them get merged

A. Pagaltzis wrote: * John Gruber <[EMAIL PROTECTED]> [2006-10-19 06:35]: I'd rather have line prefixes. I know they're harder to generate in textarea fields, because you have to do them by hand, but I'm finding it harder and harder to care about the plight of the textarea-field-writer. ~

Re: Block quotes with a blank line between them get merged

A. Pagaltzis wrote: * Waylan Limberg <[EMAIL PROTECTED]> [2006-10-18 16:20]: I considered suggesting some "force-end-of-block" marker, but that just doesn't seem right. Maybe an considered-unindented less-than character? I don't like this idea. I think that the two blank line (or three? why

Re: Block quotes with a blank line between them get merged

John Gruber wrote: I think two blank lines should break one out of a list: * First first * First second * First third * Second first * Second second I.e. that should be two lists, not one. This idea is also intertwined with the idea that there should be an alter

Re: Tightening the rules for literal `[` and `]` chars in link ids

Jacob Rus wrote: This permissiveness doesn't increase usability or friendliness. It doesn't increase usability. Substitute "readability" for the second copy of "usability". Gotta proofread better... ___ Markdown

Re: Tightening the rules for literal `[` and `]` chars in link ids

John Gruber wrote: Jacob Rus <[EMAIL PROTECTED]> wrote on 9/25/06 at 4:42 PM: It has always seemed to me that links should just be "[A-Za-z][A-Za-z0-9._-]+", and maybe 2-3 other characters, but as few as possible. There's no reason for a reference name that no one wil

Re: Tightening the rules for literal `[` and `]` chars in link ids

Michel Fortin wrote: That's why I think it'd be better to solve this while still allowing nested brackets. The other reason for supporting nested brackets is that they are already supported for the content of the link, which is often the same as the definition name. How unnatural would this b

Re: Tightening the rules for literal `[` and `]` chars in link ids

John Gruber wrote: * We could also just tighten the rules for link ref IDs all the way, and outright ban literal `[` and `]` chars in the IDs. It has always seemed to me that links should just be "[A-Za-z][A-Za-z0-9._-]+", and maybe 2-3 other characters, but as few as possible. There's

Re: Markdown comments

John Gruber wrote: The other side of the coin is that Markdown is not an XML nanny. There's an assumption with Markdown's handing of inline HTML tags that it is up to you, the author, to use raw HTML in a well-formed way. Markdown's raw HTML support is garbage-in, garbage-out. I think this tene

Re: [ANN] PHP Markdown 1.0.2b7

John Gruber wrote: Michel Fortin <[EMAIL PROTECTED]> wrote on 9/16/06 at 5:23 PM: Another big change is the automatic hashing of all Markdown-generated HTML content. Previous versions of PHP Markdown Extra were already doing this, but it was limited on block-level elements only and was don

Re: MultiMarkdown 2.0.a Released

Fletcher T. Penney wrote: On Sep 14, 2006, at 7:06 AM, Michael Sheets wrote: Is there any reason you've forked the entire Markdown bundle? The old version of the Markdown grammar you used is especially troubling as you've missed a ton of improvements we've made over the past month or so. Great

Re: Possible bug in Markdown.pl with `<<` handling

Michel Fortin wrote: But that does not mean it's the right thing to do. Does `<>` looks like a tag? I suppose it's debatable. To me it looks more like French quotes. My suggestion is just use «», and we can avoid this problem altogether. :) -Jacob ___

Re: Possible bug in Markdown.pl with `<<` handling

Fletcher T. Penney wrote: It appears that "double angles" are not properly converted when they are not in code blocks, if there is not a space following the second `<`. For example: This is not handled <>. becomes: This is not handled <>. I'm just wondering… is there any case whe

Re: getting test added to the standard test suite.

be a big hassle, and there's no reason anyone can't simply use [**test**][test] instead, which makes for much nicer references. The reference name should be text, not markup! -Jacob Rus ___ Markdown-Discuss mailing list Markdown-Discuss@six

Re: [ANN] Markdown.pl 1.0.2b7

John Gruber wrote: Allan Odgaard <[EMAIL PROTECTED]> wrote on 8/30/06 at 8:15 AM: Was there an advantage to Text::Balanced? The advantage is that it works with things like: … and I thought it was going to save me from writing tag-balancing code on my own. But the problem, as I see it, is th

Re: numbered list bug in markdown.pl?

s official spec, and keep things as unambiguous as possible. -Jacob Rus ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

Waylan Limberg wrote: On 7/9/06, Carl-Johan Kihlbom <[EMAIL PROTECTED]> wrote: I'm guessing it's because you have different indent levels. Try removing the spaces before 1-9. I'll second that. In my observation Python is very picky about the four spaces of indent, while Perl seems to notice an

numbered list bug in markdown.pl?

Hi, I'm getting what I believe to be a bug. If I put the following in markdown: 1. This is a numbered list 2. Blah 9. This is another list item 10. Ok, weird bug here 11. It's really bothering me And when I run it through markdown.pl 1.01 I get out the following: This is a numbered l