Discussion:
Block quotes with a blank line between them get merged
(too old to reply)
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
Permalink
Post by Waylan Limberg
[...]
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.
Most editors have some form of visualizing where line breaks happen.

Some editors even allow you to set the background color for your
Markdown code blocks so that they are easily identifiable ;)
John Gruber
2006-10-18 21:37:57 UTC
Permalink
Post by Jacob Rus
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
No. I don't like rules that you can't "see".

Exception that proves the rule: the "two spaces at the end of a
line for a <br />" rule.
Post by Jacob Rus
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.
It would be in addition to the current syntax, and should remain
out of your way if you don't like it.

-J.G.
Michel Fortin
2006-10-19 00:07:03 UTC
Permalink
Post by John Gruber
Post by Jacob Rus
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.
It would be in addition to the current syntax, and should remain
out of your way if you don't like it.
Me thinking about Markdown Extra: if you're using the colon for that
as previously suggested, you're breaking the definition list syntax:

Hello there!

: Is this some code or a definition?

So I will suggest something else.

It's not uncommon to see unindented code samples in email and
elsewhere denoted by a simple separator line -- I've got an
impressive number of bug reports for PHP Markdown formatted this way.
So we could build on that and introduce an unindented code block
syntax with a separator line. While the aesthetics are not as good as
indented code blocks, that syntax could prove handy when indentation
is not very practical (like, say, pasting a big code sample in a web
form).

So I propose this as an alternative code block syntax:

~~~
function db_like($first, $pattern) {
$pattern = preg_quote($pattern);
$pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
$pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
return preg_match('{^'.$pattern.'$}', $first);
}
~~~

The code block begins with three or more consecutive tildes `~` alone
on a line, and ends with the same number of tildes `~` alone on a line.


Michel Fortin
***@michelf.com
http://www.michelf.com/
John Gruber
2006-10-19 04:30:37 UTC
Permalink
Post by Michel Fortin
Me thinking about Markdown Extra: if you're using the colon
for that as previously suggested, you're breaking the
I forgot about that, and I do like that syntax. I'm not married to
":" in particular as the second code-block marker. One thing I do
remember was that the reason I took it out, rather than adding
indentation in addition to it, was that I remember thinking that
":" might be a useful character to save for something else.
Post by Michel Fortin
~~~
function db_like($first, $pattern) {
$pattern = preg_quote($pattern);
$pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
$pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
return preg_match('{^'.$pattern.'$}', $first);
}
~~~
The code block begins with three or more consecutive tildes
`~` alone on a line, and ends with the same number of tildes
`~` alone on a line.
I don't hate it, but it's not doing it for me. If you're going to
have stuff on separate lines like that, why not just use
`<pre><code>` and `</code></pre>`?

And don't forget that we'd need some sort of escape so that you
could put a literal `~~~` line in a code block.

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.

~ function db_like($first, $pattern) {
~ $pattern = preg_quote($pattern);
~ $pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
~ $pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
~ return preg_match('{^'.$pattern.'$}', $first);
~ }

One nice thing about '~' is that (on U.S. keyboards at least) it's
on the same key as '`' -- so you'd use the same key for inline
code spans as for code blocks.

-J.G.
Michel Fortin
2006-10-19 12:43:20 UTC
Permalink
Post by John Gruber
Post by Michel Fortin
~~~
function db_like($first, $pattern) {
$pattern = preg_quote($pattern);
$pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
$pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
return preg_match('{^'.$pattern.'$}', $first);
}
~~~
The code block begins with three or more consecutive tildes `~`
alone on a line, and ends with the same number of tildes `~`
alone on a line.
I don't hate it, but it's not doing it for me. If you're going to
have stuff on separate lines like that, why not just use
`<pre><code>` and `</code></pre>`?
Using `<pre><code>` for the example above means you have to manually
escape two '<' with `&lt;`. Luckily, there is no '&' in that code.
And you'd have to put the first line of the content on the same line
as `<pre><code>`.
Post by John Gruber
And don't forget that we'd need some sort of escape so that you
could put a literal `~~~` line in a code block.
You don't need that for code spans do you? You don't need that
because the final marker must be the same as the one at the beginning
-- the same applies here. If you choose the number of tilde
carefully, there is no problem.

If you have many tilde-only lines of all lengths in the code block,
it'd probably be wiser to choose an intended code block instead, if
only for clarity, but I can't see that happen very often.
Post by John Gruber
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.
~ function db_like($first, $pattern) {
~ $pattern = preg_quote($pattern);
~ $pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
~ $pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
~ return preg_match('{^'.$pattern.'$}', $first);
~ }
Personally, I don't find that aesthetically better than my proposal.
The only problem it solves is the one of two consecutive code blocks,
or a code block following a list. Other than that, it has no use; I
don't see how anyone will prefer that syntax over simple indentation,
except in the two corner cases mentioned above.

My proposal is some sort of a lazy syntax for code blocks, building
on what some people use lazily in their emails, and it has more use
than these two corner-cases. Just as you said, you don't have to use
it if you prefer the other one.
Post by John Gruber
One nice thing about '~' is that (on U.S. keyboards at least) it's
on the same key as '`' -- so you'd use the same key for inline
code spans as for code blocks.
Interesting. On my Canadian-French (CSA) keyboard, '~' is Option-Ç
and '`' is Option-À, two adjacent keys.

- - -

That said, we could also take a hybrid approach where there is only
one syntax for code block: indentation; but where you can use an
optional tilde '~' maker at the start of a new one when you need some
disambiguation:

Standard paragraph.

<title>My Page</title>

~ <title>
<?php echo $title ?>
</title>

* List item
* List item

~ <style>
<?php echo $stylesheet ?>
</style>

The downside of this approach is that it looks like some kind of list
item marker. But so do this:

Standard paragraph.

~ <title>My Page</title>

~ <title>
~ <?php echo $title ?>
~ </title>

* List item
* List item

~ <style>
~ <?php echo $stylesheet ?>
~ </style>

(Of course, the first tilde for the first code block is optional:
both code block syntaxes can be used there.)

Now let's compare to my approach:

Standard paragraph.

~~~
<title>My Page</title>
~~~

~~~
<title>
<?php echo $title ?>
</title>
~~~

* List item
* List item

~~~
<style>
<?php echo $stylesheet ?>
</style>
~~~

Which one do you prefer?


Michel Fortin
***@michelf.com
http://www.michelf.com/
Eric Daspet
2006-10-19 15:15:44 UTC
Permalink
Post by Michel Fortin
~ <title>
<?php echo $title ?>
</title>
and
Post by Michel Fortin
~ <style>
~ <?php echo $stylesheet ?>
~ </style>
Both solutions have a *major* problem : you can't copy/paste code. You
have to add/delete these ~ on each line.
IMHO the last proposal is the only one which is acceptable :

~~~
<title>
<?php echo $title ?>
</title>
~~~
--
Eric Daspet
Paul M Jones
2006-10-19 15:57:32 UTC
Permalink
Post by Eric Daspet
Post by Michel Fortin
~ <title>
<?php echo $title ?>
</title>
and
Post by Michel Fortin
~ <style>
~ <?php echo $stylesheet ?>
~ </style>
Both solutions have a *major* problem : you can't copy/paste code. You
have to add/delete these ~ on each line.
~~~
<title>
<?php echo $title ?>
</title>
~~~
Another alternative is to use opening and closing braces, perhaps
dual braces, to delimit the code block, and retain the requirement
for indenting:

{{
<style>
<?php echo $stylesheet
</style>
}}

This has the advantage of being unambiguous and mostly unobtrusive,
and you can still copy and paste code. However, it may not be in the
spirit of Markdown; I will leave it to John and Michel to say.


--

Paul M. Jones <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5. <http://solarphp.com>

Join the Solar community wiki! <http://solarphp.org>

Savant: The simple, elegant, and powerful solution for
templates in PHP. <http://phpsavant.com>
Waylan Limberg
2006-10-19 16:55:10 UTC
Permalink
Post by Eric Daspet
Post by Michel Fortin
~ <title>
<?php echo $title ?>
</title>
and
Post by Michel Fortin
~ <style>
~ <?php echo $stylesheet ?>
~ </style>
Both solutions have a *major* problem : you can't copy/paste code. You
have to add/delete these ~ on each line.
I think Eric brings up an interesting point. That is even a
shortcomming of indented code blocks, you have to either add or remove
the extra whitespace when copying or pasting the code to or from a
markdown document. Whereas, an un-indented codeblock is easily copied
and pasted with no altercations to the code. I know there have been
times when I have gotten confused when my code contains mutiple layers
of indentation. ("Did I already indent/un-indent this line?") That
said, the indented code blocks have been used for some time now
without much problem. Just an interesting observation really.
Post by Eric Daspet
~~~
<title>
<?php echo $title ?>
</title>
~~~
--
Eric Daspet
_______________________________________________
Markdown-Discuss mailing list
http://six.pairlist.net/mailman/listinfo/markdown-discuss
--
----
Waylan Limberg
***@gmail.com
A. Pagaltzis
2006-10-19 17:44:09 UTC
Permalink
Post by John Gruber
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.
~ function db_like($first, $pattern) {
~ $pattern = preg_quote($pattern);
~ $pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
~ $pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
~ return preg_match('{^'.$pattern.'$}', $first);
~ }
I find those æsthetically highly offensive.

I would suggest pipes, which I’ve seen used in the wild, although
I guess those might clash with a potential future table markup.

Other options with some precedent include hash marks and percent
signs; both are markers for single-line comments in some
languages, so code blocks prefixed with them is not an uncommon
sight. Of those I’d favour the percent sign, because while it has
much less precedent, the hash mark looks very heavy.
Post by John Gruber
Both solutions have a *major* problem : you can't copy/paste
code. You have to add/delete these ~ on each line.
Do note that that argument breaks down as soon as you consider
code blocks nested inside any other construct, which necessitates
indentation; granted, of course, that it is an uncommon use case.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Jacob Rus
2006-10-19 20:24:30 UTC
Permalink
Post by John Gruber
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.
~ function db_like($first, $pattern) {
[...]
I find those Aesthetically highly offensive.
I would suggest pipes, which I've seen used in the wild, although
I guess those might clash with a potential future table markup.
Other options with some precedent include hash marks and percent
signs; both are markers for single-line comments in some
languages, so code blocks prefixed with them is not an uncommon
sight. Of those I'd favour the percent sign, because while it has
much less precedent, the hash mark looks very heavy.
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 to
me like change for change's sake, without sufficient justification.

One final thing: In code and other preformatted text, whitespace is
significant. The current rules allow us to figure out exactly where the
beginning of the line is, so that any space character added beyond that
becomes part of the code block. In this new system, where every line
begins with, for example, a `~` character, how many spaces will be
stripped after the `~`? Any choice made here will be arbitrary, and
will disagree with the way some number of people write the other types
of blocks, such as block quotations. So if I write:

code block:

~ this is a block of code
~ starting with tildes

will that be interpreted differently than:

code block:

~ this is a block of code
~ starting with tildes

or:

code block:

~ this is a block of code
~ starting with tildes

or:

code block:

~this is a block of code
~starting with tildes

If we replace `~` with `>`, these would all be interpreted as identical
block quotations. With this new rule, a choice will need to be made
which steps on someone's toes. And as far as I can tell, for no
particular reason.

-Jacob
A. Pagaltzis
2006-10-19 21:18:42 UTC
Permalink
Post by Jacob Rus
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 to me like change for
change's sake, without sufficient justification.
Did you follow all of the thread? The initial issue was that it’s
not currently possible to have two consecutive but separate
lists. The solution to that is simple: a gap of two blank or more
blank lines between lists should force them to be separate.

But that solution falls flat when it encounters code blocks,
because may well contain consecutive blank lines, aren’t marked
with any explicit prefix character like all other block
constructs, and whitespace alone isn’t enough to overcome the
lack of prefix because lines that contain only whitespace are
considered empty by Markdown.

Hence this discussion.
Post by Jacob Rus
In this new system, where every line begins with, for example,
a `~` character, how many spaces will be stripped after the
`~`? Any choice made here will be arbitrary, and will disagree
with the way some number of people write the other types of
blocks, such as block quotations.
That is a good concern.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Jacob Rus
2006-10-19 22:05:15 UTC
Permalink
Post by Jacob Rus
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 to me like change for
change's sake, without sufficient justification.
Did you follow all of the thread? The initial issue was that it'
not currently possible to have two consecutive but separate
lists. The solution to that is simple: a gap of two blank or more
blank lines between lists should force them to be separate.
Yes, I did follow the discussion, and I quite like this solution. I
heartily endorse it, as it clears up a lot of the ugly edge cases we run
into in markdown.
But that solution falls flat when it encounters code blocks,
because may well contain consecutive blank lines, aren't marked
with any explicit prefix character like all other block
constructs, and whitespace alone isn't enough to overcome the
lack of prefix because lines that contain only whitespace are
considered empty by Markdown.
My question was mostly rhetorical, given that I have already suggested
(in fact earlier in this direct chain of responses), that it is enough
to put two completely blank lines in order to separate code blocks, as
code blocks containing empty lines should (and can currently) still be
indicated by lines containing nothing but the proper indentation.

I think that John's objection that this is not visible enough is not a
strong enough reason to change the syntax to something that in the
majority of cases is worse (i.e. would look ugly), and is only an
improvement in the rare case of two consecutive code blocks, which can
be quite sufficiently worked around by using the blank line convention).

The concern I have here is that markdown's stated goals are quite clear:
to allow the conventions of plain text email to, as much as possible,
enable the creation of well-formed and valid (x)html documents. If we
were using typewriters to write all of our documents, then of course,
there is no way in current markdown to discern the separation in two
consecutive code blocks. But computers aren't typewriters, and spaces
are real characters. In fact, we use them to denote hard line breaks
(something which I quite like, though maybe it's not visible enough
anymore? :p). There are many many areas where markdown should be made
more explicit (mainly edge case behavior should be specified, etc.), but
adding random characters at the beginning of code blocks isn't one of them.

Finally, this is only a problem at all when editing with a naïve text
editor. Just as we shouldn't necessarily cater to those limited to
little web form boxes, we also shouldn't change this syntax just for the
sake of those using inferior editors. In TextMate, all my block quotes
show up in a quite lovely shade of blue, and the lack of a character at
the beginning of each line allows me to focus on the content of the
block quote rather than this decoration. (And this last paragraph was
only mostly tongue-in-cheek. Any Markdown writers not using TextMate
are seriously missing out :)

-Jacob
Michel Fortin
2006-10-19 23:09:15 UTC
Permalink
Post by Jacob Rus
I think that John's objection that this is not visible enough is
not a strong enough reason to change the syntax to something that
in the majority of cases is worse (i.e. would look ugly), and is
only an improvement in the rare case of two consecutive code
blocks, which can be quite sufficiently worked around by using the
blank line convention).
John's proposal wasn't to change the syntax, but to create a second,
parallel syntax which can work in these situations. The old syntax
for code block would still work everywhere it works currently, the
new one could be used in ambiguous cases.

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.


Michel Fortin
***@michelf.com
http://www.michelf.com/
Jacob Rus
2006-10-20 04:37:23 UTC
Permalink
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 one tab
of indentation. If a line has nothing but four spaces or a tab, that
unambiguously suggests that the line should be an empty line in a code
block. But equally, two completely blank lines, without any spaces at
all, could quite unambiguously define the end of an environment such as
a code block.

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 user needs to examine the whitespace in detail to
figure out which is intended, I don't think it's worth adding an (ugly)
extra syntax to fix.

-Jacob
Allan Odgaard
2006-10-20 08:10:59 UTC
Permalink
Post by Jacob Rus
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 [...]
Agreed. If new syntax is going to be introduced, why not do some of
the stuff which there is currently no workaround for (other than
switch to embedded HTML) like definition lists, footnotes, tables,
providing a class for images, etc.
A. Pagaltzis
2006-10-20 01:28:20 UTC
Permalink
Post by Jacob Rus
I think that John's objection that this is not visible enough
is not a strong enough reason to change the syntax to something
that in the majority of cases is worse […] In fact, we use
[spaces] to denote hard line breaks (something which I quite
like, though maybe it's not visible enough anymore? :p).
John already said the hard break syntax is the exception that
proves the rule.
Post by Jacob Rus
Finally, this is only a problem at all when editing with
a naïve text editor. Just as we shouldn't necessarily cater to
those limited to little web form boxes, we also shouldn't
change this syntax just for the sake of those using inferior
editors.
Editors with smart autoindenting support generally make it *more*
annoying to work with whitespace-only lines, not less. Which is
a feature.


Besides what Michael already said about noone wanting to change
the syntax.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Jacob Rus
2006-10-20 04:40:22 UTC
Permalink
Post by A. Pagaltzis
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 use inferior
editors). But I completely disagree with you. In general, we want to
have whitespace-only lines continue at the same level, for instance in
code blocks, so we don't have to type out all those spaces each time.
John Gruber
2006-12-31 06:37:40 UTC
Permalink
Post by A. Pagaltzis
Post by John Gruber
~ function db_like($first, $pattern) {
~ $pattern = preg_quote($pattern);
~ $pattern = preg_replace('/(?<!\\)_/', '.', $pattern);
~ $pattern = preg_replace('/(?<!\\)%/', '.*?', $pattern);
~ return preg_match('{^'.$pattern.'$}', $first);
~ }
I find those æsthetically highly offensive.
Yeah, tildas don't feel right. Was just for example, really.
Post by A. Pagaltzis
I would suggest pipes, which I’ve seen used in the wild, although
I guess those might clash with a potential future table markup.
I'm too lazy to look back in the thread to see if I've suggested
this before, but colons might work. I think pipes are almost
certainly going to be used for tables, so count them out (although
I agree they'd feel good for code blocks, too).
Post by A. Pagaltzis
Other options with some precedent include hash marks and percent
signs; both are markers for single-line comments in some
languages, so code blocks prefixed with them is not an uncommon
sight. Of those I’d favour the percent sign, because while it has
much less precedent, the hash mark looks very heavy.
And hashes are already used for headers.


-J.G.
John Gruber
2006-12-31 06:46:02 UTC
Permalink
Post by Jacob Rus
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 user
needs to examine the whitespace in detail to figure out which
is intended, I don't think it's worth adding an (ugly) extra
syntax to fix.
Yeah, I'm not all that concerned about making it easier to create
two consecutive code blocks with nothing in between them. It'd be
nice if it were possible, but it does strike me as a rarity.

I'm more concerned about making it easier to distinguish code
blocks within lists.

But on the whole, I'd have to say I'm leaning toward not adding
any new syntax for code blocks. But if I did, it'd be some sort of
single-character line prefix, like ‘:’ or ‘%’ or maybe even some
sort of Unicode glyph.

-J.G.
Michel Fortin
2006-12-31 14:13:03 UTC
Permalink
Post by John Gruber
Yeah, I'm not all that concerned about making it easier to create
two consecutive code blocks with nothing in between them. It'd be
nice if it were possible, but it does strike me as a rarity.
It just strikes me now that if a syntax for custom attributes is
added and works with code blocks it could be used to distinguish two
consecutive code blocks. For instance:

Code block
{.php}

Code block

And this might work if you don't need any attribute:

Code block
{}

Code block


Michel Fortin
***@michelf.com
http://www.michelf.com/

Loading...