Flat code block syntax

[Thomas Nichols]

Bruce Phillips wrote on 2007/10/11 2:05:

>> Date: Tue, 09 Oct 2007 22:41:41 -0400

>> From: Michel Fortin <michel.fortin at michelf.com>

>>

>> Here are our options: ... Any opinion? Should we look into non-ASCII

>> characters too?

>>

>> Personally, my preference still goes to tilde.

>

> After comparing various characters in a real document, I also prefer

> the tilde.

>

>> Date: Mon, 08 Oct 2007 07:39:13 -0400

>> From: Michel Fortin <michel.fortin at michelf.com>

>>      ~~~~~ {.haskell}

>>      inlineNote = try $ do

>>        failIfStrict

>>        char '^'

>>        contents <- inlinesInBalanced "[" "]"

>>        return $ Note [Para contents]

>>      ~~~~~

>>

>> Here I've followed the planned syntax for adding attributes to

>> Markdown elements which was discussed some time ago on this list,

>> where attributes are in braces and class names can be added by

>> preceding them with a dot. It is still unimplemented in PHP Markdown

>> Extra, but I think Markuru has most of it. I think it's better to

>> reuse that than to create an entirely new syntax for the same purpose.

>

> I'd like to see this as well.

>

> Bruce Phillips

>

>


I've been using the ~~~ syntax for marking code blocks for a few weeks,
and it's certainly an improvement over the existing four-space indent. 
However, it can be difficult to see at a glance where one code block
begins and another ends, as in the following example:

some normal text

~~~~

some code

~~~~

some more code... no, wait...

~~~~

now *this* is code

~~~~

and this ... errrr ...

~~~~

You get the idea. This mostly becomes a problem when writing technical
docs with frequent chunks of embedded code, and the solution would
appear to be to have different markup for begin-block and end-block. 
This is the approach that the Trac wiki syntax takes, using

{{{
chunk of code here
}}}

Is there any enthusiasm are doing something similar for the proposed
Markdown extension syntax? Or will this cause conflicts (for example,
with Maruku's metadata syntax, or maybe with Pandoc)? I'm not too
concerned about the specific characters selected; perhaps

{~~~~
code
~~~~}

or

<~~~~
code
~~~~>

might cause fewer conflicts but remain easy to read.

Does anyone else feel that separate begin-block and end-block markers
would, in this rather special case where it is expected that the content
will be output verbatim, be an improvement?

-- Thomas.