Discussion:
Block quotes with a blank line between them get merged
Steve Hoelzer
2006-10-17 17:29:07 UTC
Permalink
number 1
letter B
last one
Markdown output:

<blockquote>
<p>number 1</p>

<p>letter B</p>

<p>last one</p>
</blockquote>


Is this the intended behavior? I think there should be two separate
block quote tags like this:

<blockquote>
<p>number 1</p>

<p>letter B</p>
</blockquote>

<blockquote>
<p>last one</p>
</blockquote>


Steve
Max Erickson
2006-10-17 19:59:29 UTC
Permalink
Post by Steve Hoelzer
number 1
letter B
last one
<blockquote>
<p>number 1</p>
<p>letter B</p>
<p>last one</p>
</blockquote>
Is this the intended behavior? I think there should be two
<blockquote>
<p>number 1</p>
<p>letter B</p>
</blockquote>
<blockquote>
<p>last one</p>
</blockquote>
Steve
number 1
letter B
last one
Converts to this:

<blockquote>
<p>number 1</p>

<p>letter B</p>

<p>last one</p>
</blockquote>


On the dingus anyway.


max
Már Örlygsson
2006-10-18 09:27:04 UTC
Permalink
This problem has caused me grief more than once...

I've been forced to add a paragraph of full-stops to break up the
"Some cool quote"
...
"Some other cool quote"
This feels like a bug in Markdown to me.
--
Már
Waylan Limberg
2006-10-18 13:19:15 UTC
Permalink
For whatever it is worth, both perl and php have this behavior while
python gives the expected output. I'd certainly say it is a bug. One
could very easily have a legitimate need to have two separate quotes
(perhaps from different sources) follow each other in a document.
Post by Steve Hoelzer
number 1
letter B
last one
<blockquote>
<p>number 1</p>
<p>letter B</p>
<p>last one</p>
</blockquote>
Is this the intended behavior? I think there should be two separate
<blockquote>
<p>number 1</p>
<p>letter B</p>
</blockquote>
<blockquote>
<p>last one</p>
</blockquote>
Steve
_______________________________________________
Markdown-Discuss mailing list
http://six.pairlist.net/mailman/listinfo/markdown-discuss
--
----
Waylan Limberg
***@gmail.com
Allan Odgaard
2006-10-18 13:27:55 UTC
Permalink
Post by Waylan Limberg
For whatever it is worth, both perl and php have this behavior while
python gives the expected output. I'd certainly say it is a bug [...]
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 item





* much further down.
Michel Fortin
2006-10-18 13:43:37 UTC
Permalink
Post by Waylan Limberg
For whatever it is worth, both perl and php have this behavior while
python gives the expected output. I'd certainly say it is a bug. One
could very easily have a legitimate need to have two separate quotes
(perhaps from different sources) follow each other in a document.
I don't see that as a bug; I think it's the intended behaviour. This
Post by Waylan Limberg
Markdown allows you to be lazy and only put the `>` before the first
This is a blockquote with two paragraphs. Lorem ipsum dolor
sit amet,
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae,
risus.
Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
Suspendisse
id sem consectetuer libero luctus adipiscing.
[1]: http://daringfireball.net/projects/markdown/syntax#blockquote

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 the two paragraphs, but changing that
would probably break some people's text.

As a workaround, you can insert an HTML comment between the two
blockquotes. It'd be nice too if three consecutive blank lines would
clear the blockquote.


Michel Fortin
***@michelf.com
http://www.michelf.com/
A. Pagaltzis
2006-10-18 13:56:46 UTC
Permalink
It'd be nice too if three consecutive blank lines would clear
the blockquote.
Two should suffice, IMO.

I always found it extremely annoying that Markdown provides no
way to express multiple consecutive blockquotes, lists or code
blocks, other than by using workarounds like inserting comments
or other crud like `<div style="display:none"></div>`.

(An added problem with breaking out of code blocks is that
Markdown considers lines consisting only of whitespace to be
blank, so you couldn’t have code blocks with consecutive blank
lines in them.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Waylan Limberg
2006-10-18 14:18:05 UTC
Permalink
Post by A. Pagaltzis
It'd be nice too if three consecutive blank lines would clear
the blockquote.
Two should suffice, IMO.
I always found it extremely annoying that Markdown provides no
way to express multiple consecutive blockquotes, lists or code
blocks, other than by using workarounds like inserting comments
or other crud like `<div style="display:none"></div>`.
I was going to bring code blocks into this discussion as well. The
same thinking applies to both and had been an annouance of mine for
some time as well.
Post by A. Pagaltzis
(An added problem with breaking out of code blocks is that
Markdown considers lines consisting only of whitespace to be
blank, so you couldn't have code blocks with consecutive blank
lines in them.)
Which brings us full circle. We have code blocks and blockquotes that
may have multiple line breaks, and we have multiple blocks (code or
quotes) seperated by line breaks. How can markdown know which is
intended? I considered suggesting some "force-end-of-block" marker,
but that just doesn't seem right.
--
----
Waylan Limberg
***@gmail.com
A. Pagaltzis
2006-10-18 14:30:20 UTC
Permalink
I considered suggesting some "force-end-of-block" marker, but
that just doesn't seem right.
Maybe an considered-unindented less-than character?
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Sed quis lectus vitae mauris bibendum dapibus. Sed pretium
dolor vel nisl semper hendrerit.
<
Vivamus erat. Mauris lacus. Nam sollicitudin, sapien vitae
hendrerit interdum, purus augue vehicula magna, id bibendum
nibh dui vel enim.
Or:

The following two code samples function identically:

$foo = $bar = $baz;

<

$bar = $baz; $foo = $bar;

Not exactly *pretty*… but doesn’t overly offend my sense
aesthetic either and also seems to me to reads reasonably
intuitively when looking at the Markdown source.

Or maybe have it look like a horizontal rule:

The following two code samples function identically:

$foo = $bar = $baz;

<<<<

$bar = $baz; $foo = $bar;

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Jacob Rus
2006-10-18 17:33:04 UTC
Permalink
Post by A. Pagaltzis
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
three again?) convention would be perfectly fine. As a way to
explicitly continue a list (despite a few empty-looking lines), a user
could perhaps indent out to the level of the list. For instance

* This is a list item
* This is another list item

With some long and complex paragraphs


* We wanted two empty lines above to visually clear the way for
this third list item, which could otherwise look cluttered.

So our method was to explicitly add an indent to the blank
lines so that the list is continued.


* The nice thing about this method is that it's easy to
unambiguously parse the document. Any single blank lines
can essentially be ignored (though they end paragraphs),
but two newlines in a row with no spaces between can always
exit out of any block-level elements, back to the top level.

* This also seems to me to be perfectly consistent with the
official markdown specification.


* This is a new list, because the previous line did not continue
the indentation.

What do people think?

-Jacob
John Gruber
2006-10-18 15:06:02 UTC
Permalink
Post by Michel Fortin
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 the two
paragraphs, but changing that would probably break some
people's text.
Yeah, it's not a bug, but it probably should be considered a
mistake in the syntax.

I don't take breaking existing Markdown-formatted text lightly,
but I don't want to be too cautious about improving the syntax
going forward just to avoid breaking existing text.

We should change this.

Code blocks are another issue, though, because they don't have
explicit line markers.

The only way I can think of to support multiple consecutive code
blocks (while still allowing a single code block to contain two,
three, or more consecutive blank lines) would be to introduce an
additional (optional) marker for code blocks. Way back when in
2003 while I was working on the original Markdown syntax, code
blocks were delimited by colons:

: sub foo {
: print "foo";
: }

Same as:

sub foo {
print "foo";
}

This would also help clarify things when you want to put a code
block inside an already-indented paragraph-mode list item.

To be clear, this would be *in addition to* the current "just
indent it" rule for code blocks. It would be a second, more
explicit, way to specify them.

-J.G.
John Gruber
2006-10-18 15:09:35 UTC
Permalink
Post by Allan Odgaard
In that case one could argue that there are a few related
bugs, e.g. in the following the “much further down”
1. First item
2. Second item
3. Third item
* much further down.
Again, not a bug, but a mistake in the syntax design.

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 alternate explicit syntax for code blocks, though, because
otherwise what would happen if you were making a list where one of
the items contained a code block with two blank lines?

-J.G.
Jacob Rus
2006-10-18 16:13:34 UTC
Permalink
Post by John Gruber
* 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 alternate explicit syntax for code blocks, though, because
otherwise what would happen if you were making a list where one of
the items contained a code block with two blank lines?
That's easy; the user will remember to add spaces (or tabs) up to the
indent which starts a code block. For instance (where I'm highlighting
spaces with a drawn glyph. Interpret those as " ":

This is some example markdown with blank lines in code blocks:

* First first
* First second

First second has some paragraphs inside

␣␣␣␣a = {"and", "some", "code", "blocks"}
␣␣␣␣
␣␣␣␣
␣␣␣␣b = {"and", "some", "blank", "lines", "in", "those"}

* First third

␣␣␣␣c = {"more", "random", "monospaced", "stuff"}

␣␣␣␣d = {"this", "one", "starts", "a", "new",
␣␣␣␣ "code block", "as there was a line before",
␣␣␣␣ "it", "without the requisite code block", "indent"}


* Second first (note that the previous two lines are very empty)

I think that this interpretation is the logical (unambiguous, strict)
interpretation of the official markdown spec. In other words, if you
intend to continue a code block, just keep the indent going. If you
intend to end it, then stop indenting. Blank lines within the code
block are then no problem.

Incidentally, I don't think that we need any more explicit symbolic
marker for code blocks. One of the things I most like about markdown's
syntax is that a simple indentation puts us into a code block, without
any unnecessary clutter.

-Jacob
Waylan Limberg
2006-10-18 16:28:44 UTC
Permalink
Post by Jacob Rus
Post by John Gruber
* 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 alternate explicit syntax for code blocks, though, because
otherwise what would happen if you were making a list where one of
the items contained a code block with two blank lines?
That's easy; the user will remember to add spaces (or tabs) up to the
indent which starts a code block. For instance (where I'm highlighting
* First first
* First second
First second has some paragraphs inside
␣␣␣␣a = {"and", "some", "code", "blocks"}
␣␣␣␣
␣␣␣␣
␣␣␣␣b = {"and", "some", "blank", "lines", "in", "those"}
* First third
␣␣␣␣c = {"more", "random", "monospaced", "stuff"}
␣␣␣␣d = {"this", "one", "starts", "a", "new",
␣␣␣␣ "code block", "as there was a line before",
␣␣␣␣ "it", "without the requisite code block", "indent"}
* Second first (note that the previous two lines are very empty)
I think that this interpretation is the logical (unambiguous, strict)
interpretation of the official markdown spec. In other words, if you
intend to continue a code block, just keep the indent going. If you
intend to end it, then stop indenting. Blank lines within the code
block are then no problem.
Incidentally, I don't think that we need any more explicit symbolic
marker for code blocks. One of the things I most like about markdown's
syntax is that a simple indentation puts us into a code block, without
any unnecessary clutter.
Now that you mention it, I remember thinking it should work that way
the first time I encountered the problem. Unfortunetly it does not in
any implementation that I am aware of.

Additionaly, we have the issue that the whitespace is not visable to
the editor/writer which could make it difficult for document
editors/writers to debug display problems. that said, it still makes
sense to me.
--
---
Allan Odgaard
2006-10-18 16:50:55 UTC