How could Markdown possibly change this now?
If you’re writing in a forum where bounding asterisks as literal asterisks are
a thing you want, then you don’t want Markdown.
—J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
On 17 Oct 2012, at 9:40pm, Alan Hogan cont...@alanhogan.com wrote:
I do have to warn you, however. While a number of maintainers have gone to
great lengths to maximize interoperability, there *is* no BDFL (benevolent
dictator for life)
Yes there is. I believe Markdown has thrived and
On 26 Feb 2009, at 7:54 PM, David E. Wheeler wrote:
3. A hypothetical official table syntax for Markdown will almost
certainly look very much, if not exactly, like Michel's table
syntax in PHP Markdown Extra.
Well, perhaps it's foolish of me, but since I'd already spent
several hours
On 19 Feb 2009, at 12:53 PM, David E. Wheeler wrote:
Thanks John. Like I said, I prefer it to a colon because, in my mind
at least, a colon goes at the end of things, not the beginning of
things.
I lean toward colon because I see colons coming not at the beginning
or end, but in the
On 18 Feb 2009, at 1:44 PM, David E. Wheeler wrote:
What I came up with is a single character change to the PHP Markdown
Extra syntax. I just published a detailed explanation of my thoughts
and reasoning for this on [my
On Mar 2, 2008, at 7:49 PM, Aristotle Pagaltzis wrote:
This is actually my second biggest complaint with Markdown. As I
understand, John was originally going to allow numbered lists to
start at numbers other than 1, but then discovered that the HTML4
WG labelled the `start` attribute of lists
On Feb 3, 2008, at 2:46 PM, Aristotle Pagaltzis wrote:
Regrettably, there still isn’t one registered for Markdown. If my
reading of [RFC 4288] is correct, John shouldn’t have any trouble
registering eg. `text/vnd.daringfireball.markdown` using the
application form at
On Dec 14, 2007, at 3:22 AM, Jacob Rus wrote:
Just out of curiosity, what's the point?
Performance, I would guess.
-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
On Nov 2, 2007, at 8:12 PM, Trent Mick wrote:
I'm announcing python-markdown2 -- another Python implementation of
Markdown. (MIT license.)
Nice.
-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
On Sep 16, 2007, at 8:49 AM, Milian Wolff wrote:
What do you think about that? Is this a bug in Markdown.pl ?
Yeah, I think it's a bug, or at least a semi-bug, in Markdown.pl.
Note that you don't get the needless empty title attribute with this:
![this][f]
[f]: /foo.jpg
Download:
http://daringfireball.net/projects/downloads/Markdown_1.0.2b8.tbz
Changes from 1.0.2b7:
+ Fixed bug with nested raw HTML tags that contained
attributes. The problem is that it uses a backreference in
the expression that it passes to gen_extract_tagged, which
I've updated the MarkdownTest package. The test script is
unchanged, but the Tests folder contains new tests,
corresponding to the bugs fixed in 1.0.2b8.
http://daringfireball.net/projects/downloads/MarkdownTest_1.0_2007-05-09.tgz
-J.G.
___
Matt Kraai [EMAIL PROTECTED] wrote on 5/9/07 at 7:30 PM:
The patch was originally from Joey Hess, so please credit him instead.
Noted. Thanks for the correction.
-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
Mark Eli Kalderon [EMAIL PROTECTED] wrote on 5/4/07 at 1:12 AM:
Is this a bug?
[WIMP](http://en.wikipedia.org/wiki/WIMP_(computing))
Bug. Thanks for reporting it.
-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
Michel Fortin [EMAIL PROTECTED] wrote on 5/3/07 at 10:32 PM:
[WIMP](http://en.wikipedia.org/wiki/WIMP_(computing))
This one I'm sure it's a bug. It returns the same output as your example
above:
pa href=http://en.wikipedia.org/wiki/WIMP_(computingWIMP/a)/p
Which makes me think
Michel Fortin [EMAIL PROTECTED] wrote on 5/2/07 at 11:32 PM:
I wouldn't change the default for the reasons John has
enumerated. But I wouldn't remove the configuration option so
easily either so people can still choose the HTML 4 syntax if
they like. HTML 5 accepts both syntaxes as conformant
Matt Kraai [EMAIL PROTECTED] wrote on 5/2/07 at 12:30 AM:
The problem is that it uses a backreference in the expression that it
passes to gen_extract_tagged, which is broken when Text::Balanced
wraps it in parentheses. The attached patch fixes it.
Thanks for the fix.
-J.G.
Jacob Rus [EMAIL PROTECTED] wrote on 1/7/07 at 5:07 PM:
This stuff should be consistent, and any paragraph with 4
spaces of indentation should be considered to exit any block
elements, while any between 4 and 7 spaces should be considered
to continue the block.
Yes, this is a bug.
-J.G.
A. Pagaltzis [EMAIL PROTECTED] wrote on 1/1/07 at 2:08 PM:
No, he said a *literal* non-breaking space. The `nbsp;` entity,
in case you didn’t know, is not special; like all entities, it
merely stands for a character that also has a regular character
code: 160 in the ISO-Latin-* encodings and
Michel Fortin [EMAIL PROTECTED] wrote on 12/31/06 at 8:48 AM:
Indeed it is. The online document was reverted to an older
version at some point in early 2006 or late 2005. I attached
to this email the more up-to-date document from March 2005
when I translated it [in French][fr] and kept a copy
Ken Scott [EMAIL PROTECTED] wrote on 12/31/06 at 6:34 PM:
403 Forbidden, for me just now.
My bad. That should have been:
http://daringfireball.net/projects/downloads/Markdown_1.0.2b7.tbz
-J.G.
___
Markdown-Discuss mailing list
Bob Hutchison [EMAIL PROTECTED] wrote on 12/29/06 at 12:04 PM:
While I can live with the HTML style it would be really nice to
have something else
Especially something that didn't pass the comment through to the
generated HTML.
Right. That would clearly be the biggest reason to add a
Andrea Censi [EMAIL PROTECTED] wrote on 12/29/06 at 10:49 PM:
Markdown.pl ignores the leading blank line in the code block.
Is this intended behaviour?
Yes.
-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
Andrea Censi [EMAIL PROTECTED] wrote on 12/30/06 at 11:13 AM:
Consider the input:
---
`There is a literal backtick (\`) here.`
`There is a literal backtick (\\`) here.`
``There is a literal backtick (`) here.``
---
The documentation says that line 2 and 3 are equivalent.
A. Pagaltzis [EMAIL PROTECTED] wrote on 12/29/06 at 7:21 PM:
In other words, a paragraph, once started, eats everything
until a blank line?
Except blockquotes and headings.
And I think that should change. I think every block-level element
should be separated by a blank line.
-J.G.
Jacob Rus [EMAIL PROTECTED] wrote on 10/20/06 at 12:37 AM:
But I posit that this is really a non-issue, as there is
almost no use for multiple consecutive code blocks with no
commentary in between. I have never seen such a pattern used,
and if in the one time in a million it comes up, the
Andrea Censi [EMAIL PROTECTED] wrote on 12/28/06 at 11:46 PM:
I was surprised to see it's already comparable in speed. :-D
Probably the magic is in the line-oriented parser: I'm using regexp
only for span-level elements.
Yeah, I'll bet yours makes fewer copies of the entire source
input. With
Andrea Censi [EMAIL PROTECTED] wrote on 12/27/06 at 7:11 PM:
In particular, what do you think of this (proposed) syntax for adding
meta-data to span-level elements?
http://maruku.rubyforge.org/maruku.html#future
8.1. A syntax for specifying meta-data for span-level elements
Your use of braces
Andrea Censi [EMAIL PROTECTED] wrote on 12/28/06 at 7:57 PM:
About this, Michel Fortin referred to an old thread (2005) about
meta-data syntax.
I resurrected it and tried to summarize:
http://maruku.rubyforge.org/markdown_extra2.html
http://maruku.rubyforge.org/markdown_extra2.md
Any
Andrea Censi [EMAIL PROTECTED] wrote on 12/27/06 at 7:11 PM:
Maruku implements the original Markdown syntax and all the
improvements in PHP Markdown Extra. Moreover, it implements some ideas
from MultiMarkdown, and adds a syntax for specifying metadata for
block elements.
Maruku looks very
Andrea Censi [EMAIL PROTECTED] wrote on 12/28/06 at 10:47 PM:
Yes. Something very similar to this is what I'm planning to add.
..which is?(I can't bear the suspense :-) )
I'm not holding back. What I mean is that I'm not certain.
I can't think of anything to complain about in the
Michel Fortin [EMAIL PROTECTED] wrote on 10/18/06 at
9:43 AM:
Of course, it can be debated if this is desirable or not, but
both PHP Markdown and Perl Markdown are coherent with the
syntax description. My personal take is that it would be
better to require a `` on the blank line between
Allan Odgaard [EMAIL PROTECTED] wrote on 10/18/06 at
3:27 PM:
In that case one could argue that there are a few related
bugs, e.g. in the following the “much further down”
appears as a sub item of the third item:
Some Items:
1. First item
2. Second item
3. Third
[EMAIL PROTECTED] wrote on 10/17/06 at 8:28 PM:
p.s. anyone here have reaction to the
analysis of markdown from ivan kristic
for the one-laptop-per-child project?
It's OK, I guess, but certainly nothing I'd allow the name
Markdown to apply to. Some of his criticism of Markdown's 1.0
syntax
Allan Odgaard [EMAIL PROTECTED] wrote on 10/9/06 at
6:33 PM:
Now, it’s no problem to add another, but I’ve just never came
across mdml, nor was it mentioned when I asked JG for which
extensions are in use.
I don't like it at all, and certainly won't use or endorse it.
What's the ml part?
Fletcher T. Penney [EMAIL PROTECTED] wrote on 10/9/06
at 6:20 PM:
I was not too keen on .mdml, but did like the .mdtext
that someone else pointed out. All in all, I don't much care
what a consensus extension is, but would happily use it if
there was one.
If you're going to go to six
Michel Fortin [EMAIL PROTECTED] wrote on 10/9/06 at
9:33 PM:
I haven't tried it inside PHP Markdown yet, but I've tested
`mb_strlen` and it seems to treat any invalid UTF-8 byte
sequence as individual characters. So the neat result is that
text in ISO Latin, Windows Latin, or Mac Roman will
Allan Odgaard [EMAIL PROTECTED] wrote on 10/8/06 at
1:16 AM:
Example:
% Markdown.pl $'Test\n=\n'
h1Test/h1
While it doesn’t matter, I would expect the intended
output to be:
h1Test/h1
Ah, gotcha. Totally agreed, fixed.
-J.G.
So while we're fixing Setext-style headings, here are my thoughts
on how to make them less ambiguous. One overall problem in
Markdown 1.0's syntax is that it isn't clear when you need blank
lines to separate block-level constructs.
I feel strongly now that this was a mistake, and that the rules
Allan Odgaard [EMAIL PROTECTED] wrote on 10/7/06 at
6:27 AM:
Noticed the patterns for setext style headings are:
^(.+)[ \t]*\n=+[ \t]*\n+
Should be:
^(.+?)[ \t]*\n=+[ \t]*\n+
Why? I can't see where this would make a difference.
-J.G.
So here's an interesting bug I just discovered:
[Like this][d]: [here][h].
[d]: foo
[h]: bar
The output here should be:
a href=fooLike this/a: a href=barhere/a.
But instead the output is completely empty. I see this bug in both
Markdown.pl and PHP Markdown.
The
John Gruber [EMAIL PROTECTED] wrote on 9/25/06 at 3:09 PM:
My thinking is that this can be solved by changing the rules for
link IDs to state that they can only contain embedded literal
brackets if (a) they're properly nested; or (b) they're backslash
escaped.
Objections or suggestions
Michel Fortin [EMAIL PROTECTED] wrote on 9/18/06 at 6:26 PM:
But consider these two comments:
!-- Header ---
!-- this -- or that --
Your proposal would change them to:
!--\-\-\-\- Header -\-\-\-\-\--
!-- this -\- or that --
My plain English rules were
Jacob Rus [EMAIL PROTECTED] wrote on 9/18/06 at 7:05 PM:
Let's please stick to this philosophy, and not complicate matters. If
authors can't handle -- inside comments, and the browser chokes, it is
most certainly not markdown's fault, and any change we make here to
original comments (at
Michel Fortin [EMAIL PROTECTED] wrote on 9/16/06 at 6:03 PM:
li id=fn:1
pAnd that's the footnote.
a href=#fnref:1 rev=footnote#8617;/a/p
/li
I'll try to find more time to comment on this soon, but overall it
looks like a great job.
One suggestion on that output above.
Kailoa Kadano [EMAIL PROTECTED] wrote on 8/31/06 at 11:03 AM:
It is weird, but I agree that it is correct. Judging from your
reaction, the result seems to be serendipitous with respect to
Markdown.pl. Unfortunately, not all implementations seem to match...
What result does the Python
A. Pagaltzis [EMAIL PROTECTED] wrote on 7/13/06 at 5:45 AM:
But I don’t have documents any that rely on tiny indentation to
mark up nested lists. There is nothing in the docs that specifies
the behaviour of this case in detail. In fact I was surprised by
the actual behaviour.
So I would
47 matches
Mail list logo
