From beau at beausmith.com  Wed Jun  3 14:17:17 2009
From: beau at beausmith.com (Beau Smith)
Date: Wed, 3 Jun 2009 11:17:17 -0700
Subject: Markdown plugin produces hash instead of content
Message-ID: <2AFDD312-2383-40B2-85EE-B94694C029D0@beausmith.com>

I love Markdown. But occasionally I run into this rendering bug which  
is very frustrating. I recently found it when using Markdown to format  
the latest version of the [mt:Entries docs][1] ([Markdown version][2]  
mentioned in [Case 79762][3])

As posted as a comment on the [Movable Type Markdown plugin page](http://plugins.movabletype.org/markdown/index.html 
)...

---
**Bug report in Markdown 1.0.1**

Using the following code in an entry body will produce a hash value  
instead of the desired code:

Input:

     <div></div>a
     <p>a
     </p>
     <div></div>

Output:

     a 7ac950327848428d111704c3b71bac6f

I can also produce using [this markdown formatted version of the  
mt:Entries docs][2] (mentioned in [Case 79762][3]) in an entry body.  
Once published find the hash under the heading "Combination of  
Attributes and Modifiers".

This same behavior occurs when using the preview command in [TextMate](http://macromates.com/ 
).

[2]: http://bugs.movabletype.org/default.asp?pg=pgDownload&pgType=pgFile&ixBugEvent=462439&ixAttachment=11283&sTicket=&sFileName=entries.mdown
[3]: http://bugs.movabletype.org/default.asp?79762
---

I've searched for more info on this bug but can't find anything.  
Hoping someone on this list may have a fix.

Thanks much.

_beau





From beau at beausmith.com  Wed Jun  3 14:53:13 2009
From: beau at beausmith.com (Beau Smith)
Date: Wed, 3 Jun 2009 11:53:13 -0700
Subject: Markdown plugin produces hash instead of content
In-Reply-To: <2AFDD312-2383-40B2-85EE-B94694C029D0@beausmith.com>
References: <2AFDD312-2383-40B2-85EE-B94694C029D0@beausmith.com>
Message-ID: <ADCC32BC-7CDA-4742-830E-AADD05B8F640@beausmith.com>

On Jun 3, 2009, at 11:17 AM, Beau Smith wrote:

> Output:
>
>    a 7ac950327848428d111704c3b71bac6f


D'oh! Forgot the html in the output.

Output:

     <div></div>a 7ac950327848428d111704c3b71bac6f <div></div>


_beau






From slacombe9 at gmail.com  Sun Jun 14 17:57:52 2009
From: slacombe9 at gmail.com (=?iso-8859-1?B?U+li?=)
Date: Sun, 14 Jun 2009 17:57:52 -0400
Subject: Automatic html saving
In-Reply-To: <20090614214209.GA23437@gmail.com>
References: <20090614214209.GA23437@gmail.com>
Message-ID: <20090614215752.GB23437@gmail.com>

Hi,

Someone have a tip to automatically convert a .mkd or .md in .html ? 
In particularly with vim.

Presently I use the markdown command.

Thanks in advance

S?b



From shuff at vecna.org  Mon Jun 15 09:23:52 2009
From: shuff at vecna.org (Steve Huff)
Date: Mon, 15 Jun 2009 09:23:52 -0400
Subject: Automatic html saving
In-Reply-To: <20090614215752.GB23437@gmail.com>
References: <20090614214209.GA23437@gmail.com>
	<20090614215752.GB23437@gmail.com>
Message-ID: <7D1775BD-8F20-4CC0-A182-BFAA904B8110@vecna.org>


On Jun 14, 2009, at 5:57 PM, S?b wrote:

> Someone have a tip to automatically convert a .mkd or .md in .html ?
> In particularly with vim.
>
> Presently I use the markdown command.


i don't know how "automatically" you need, but the following command  
is part of my vim toolbox:

" Markdown filtering
command -range=% Markdown <line1>,<line2>!markdown

this means that i can write a buffer in Markdown syntax, then  
run :Markdown (or some abbreviation thereof) and the contents of the  
buffer are replaced with the translated HTML.

-steve

--
If this were played upon a stage now, I could condemn it as an  
improbable fiction. - Fabian, Twelfth Night, III,v
http://five.sentenc.es

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2209 bytes
Desc: not available
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090615/4c854533/attachment.bin>

From waysoftheearth at yahoo.com.au  Sun Jun 21 04:20:28 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Sun, 21 Jun 2009 18:20:28 +1000
Subject: Query about emphasis
Message-ID: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>

Hello List,

Firstly, I was very impressed when I tried markdown 2.0 recently.  Fantastic
work all!

I have a query about the treatment of emphasis.

I realise that the horse has bolted, and changes to currently supported
functionality are unlikely to attract support.  However, there does seem (at
least in my tiny mind) to be a mis-match between the following stated goal
and the present implementation of emphasis:


Quote (from http://daringfireball.net/projects/markdown/syntax#philosophy):
    Markdown?s syntax is comprised entirely of punctuation characters, which
punctuation characters have been carefully chosen so as to *look like what
they mean*.


It seems to me that *writers* who are not programmers are thinking in terms
of italic, bold, underlined, or stuckout text and so on.  A *writer* is not
thinking about abstract concepts like <em> or <strong> or any HTML at all.

During a process of "marking down" some informally structured text files in
order to get them into HTML, I have encountered the following "syntax" :

    Here is some plain text that looks /italic/.
    Here is some plain text that looks -s-t-r-u-c-k-o-u-t-.
    Here is some plain text that looks _underlined_.
    Here is some plain text that looks *bold*.

This issue I see is that stylistic information intended by the author is *
lost* by the current implementation.  Markdown supports only two flavours of
emphasis (<em> and <strong>) while writers can intend at least the four
flavours of emphasis mentioned above (bold, italic, underlined, struck
out).  I.e., information is "lost in translation".

Also, there is no guarantee that browsers will render <em> or <strong> in
the style intended by the author, because <em> and <strong> have
intentionally been abstracted away from the writer's concepts of bold,
italic, underlined and so on.  I don't see that those abstractions are
helpful where readability of the plain text source file, and the goal quoted
(above) are the primary concerns.

One possible solution to my issue would be something like this:

    /some text/         -->  <font style="italic">some text</font>
    -s-o-m-e-t-e-x-t-   -->  <font style="struckout">some text</font>
    _some text_         -->  <font style="underline">some text</font>
    *some text*         -->  <font style="bold">some text</font>

I anticipate that there probably won't be much appetite for changing the
markdown tool, so I intend to have a go at implementing the above for my own
"local" markdown (with approximately zero knowledge of Python).  However, I
would be interested what other list members think about this?  Does anyone
else see it as an issue or not?

Thanks all, and GREAT WORK markdown team!

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090621/f7335cad/attachment.html>

From joehall at gmail.com  Sun Jun 21 06:24:46 2009
From: joehall at gmail.com (Joseph Lorenzo Hall)
Date: Sun, 21 Jun 2009 06:24:46 -0400
Subject: Query about emphasis
In-Reply-To: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
Message-ID: <928946aa0906210324v61f2fc37ya8ea2e79186a4a81@mail.gmail.com>

Markdown 2.0?

On Sunday, June 21, 2009, Simon Bull <waysoftheearth at yahoo.com.au> wrote:
> Hello List,
>
> Firstly, I was very impressed when I tried markdown 2.0 recently.? Fantastic work all!
>
> I have a query about the treatment of emphasis.
>
> I realise that the horse has bolted, and changes to currently supported functionality are unlikely to attract support.? However, there does seem (at least in my tiny mind) to be a mis-match between the following stated goal and the present implementation of emphasis:
>
>
> Quote (from http://daringfireball.net/projects/markdown/syntax#philosophy):
> ??? Markdown?s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean.
>
>
> It seems to me that *writers* who are not programmers are thinking in terms of italic, bold, underlined, or stuckout text and so on.? A *writer* is not thinking about abstract concepts like <em> or <strong> or any HTML at all.
>
> During a process of "marking down" some informally structured text files in order to get them into HTML, I have encountered the following "syntax" :
>
> ??? Here is some plain text that looks /italic/.
> ??? Here is some plain text that looks -s-t-r-u-c-k-o-u-t-.
> ??? Here is some plain text that looks _underlined_.
> ??? Here is some plain text that looks *bold*.
>
> This issue I see is that stylistic information intended by the author is lost by the current implementation.? Markdown supports only two flavours of emphasis (<em> and <strong>) while writers can intend at least the four flavours of emphasis mentioned above (bold, italic, underlined, struck out).? I.e., information is "lost in translation".
>
> Also, there is no guarantee that browsers will render <em> or <strong> in the style intended by the author, because <em> and <strong> have intentionally been abstracted away from the writer's concepts of bold, italic, underlined and so on.? I don't see that those abstractions are helpful where readability of the plain text source file, and the goal quoted (above) are the primary concerns.
>
> One possible solution to my issue would be something like this:
>
> ??? /some text/???????? -->? <font style="italic">some text</font>
> ??? -s-o-m-e-t-e-x-t-?? -->? <font style="struckout">some text</font>
> ??? _some text_???????? -->? <font style="underline">some text</font>
> ??? *some text*???????? -->? <font style="bold">some text</font>
>
> I anticipate that there probably won't be much appetite for changing the markdown tool, so I intend to have a go at implementing the above for my own "local" markdown (with approximately zero knowledge of Python).? However, I would be interested what other list members think about this?? Does anyone else see it as an issue or not?
>
> Thanks all, and GREAT WORK markdown team!
>
> Simon
>
>
>
>
>
>
>

-- 
Joseph Lorenzo Hall
ACCURATE Postdoctoral Research Associate
UC Berkeley School of Information
Princeton Center for Information Technology Policy
http://josephhall.org/

From waysoftheearth at yahoo.com.au  Sun Jun 21 07:28:51 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Sun, 21 Jun 2009 21:28:51 +1000
Subject: Query about emphasis
In-Reply-To: <7a70dba0906210426n477fe9a4h38dffdb6a466491e@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
	<928946aa0906210324v61f2fc37ya8ea2e79186a4a81@mail.gmail.com>
	<7a70dba0906210426n477fe9a4h38dffdb6a466491e@mail.gmail.com>
Message-ID: <7a70dba0906210428r6522a0f6ma9b45a3fea0893ed@mail.gmail.com>

My apologies for the ambiguity -- I was referring to the python
implementation which seems to be known as markdown2 (see
http://pypi.python.org/pypi/markdown2/1.0.1.12).

Simon

On Sun, Jun 21, 2009 at 9:26 PM, Simon Bull <simonbull at gmail.com> wrote:

> My apologies for the ambiguity -- I was referring to the python
> implementation which seems to be known as markdown2 (see
> http://pypi.python.org/pypi/markdown2/1.0.1.12).
>
> Simon
>
> On Sun, Jun 21, 2009 at 8:24 PM, Joseph Lorenzo Hall <joehall at gmail.com>wrote:
>
>> Markdown 2.0?
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090621/cb2a5e41/attachment.htm>

From sgbotsford at gmail.com  Sun Jun 21 09:40:59 2009
From: sgbotsford at gmail.com (Sherwood Botsford)
Date: Sun, 21 Jun 2009 07:40:59 -0600
Subject: Query about emphasis
In-Reply-To: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
Message-ID: <534004cc0906210640i57ae8a69u159d6e7962863f88@mail.gmail.com>

>     /some text/         -->  <font style="italic">some text</font>
>     -s-o-m-e-t-e-x-t-   -->  <font style="struckout">some text</font>
>     _some text_         -->  <font style="underline">some text</font>
>     *some text*         -->  <font style="bold">some text</font>
>
> I anticipate that there probably won't be much appetite for changing the
> markdown tool, so I intend to have a go at implementing the above for my own
> "local" markdown (with approximately zero knowledge of Python).  However, I
> would be interested what other list members think about this?  Does anyone
> else see it as an issue or not?
>
> Thanks all, and GREAT WORK markdown team!
>
>
If you implement it, keep  it simple:  <i>some text</i>
Or possibly if you want more control <span class="italic">some text</span>?

One of the things I don't like about the markdown spec is that while I can
do strong or emphasis I can't do strong emphasis.


Warning:  Written before coffee.



-- 
Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
[Note:  THREE s's in the web link]
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090621/45db1edf/attachment.html>

From pagaltzis at gmx.de  Sun Jun 21 10:33:24 2009
From: pagaltzis at gmx.de (Aristotle Pagaltzis)
Date: Sun, 21 Jun 2009 16:33:24 +0200
Subject: Query about emphasis
In-Reply-To: <534004cc0906210640i57ae8a69u159d6e7962863f88@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
	<534004cc0906210640i57ae8a69u159d6e7962863f88@mail.gmail.com>
Message-ID: <20090621143324.GA25538@klangraum.plasmasturm.org>

* Sherwood Botsford <sgbotsford at gmail.com> [2009-06-21 15:45]:
> If you implement it, keep  it simple:  <i>some text</i>
> Or possibly if you want more control <span class="italic">some text</span>?

That?s not more control. In terms of semantics and stylability,
the two ways are entirely equivalent.

> One of the things I don't like about the markdown spec is that
> while I can do strong or emphasis I can't do strong emphasis.

You __*certainly*__ can.

(Actually you don?t even need to switch syntax markers: triple
asterisks or underscores will work just as well. But using two
different styles together makes the source text easier to read
for a human.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

From waylan at gmail.com  Sun Jun 21 23:14:07 2009
From: waylan at gmail.com (Waylan Limberg)
Date: Sun, 21 Jun 2009 23:14:07 -0400
Subject: Query about emphasis
In-Reply-To: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
Message-ID: <e5d795bb0906212014u5df0b8e1t3262b0f85efbea8@mail.gmail.com>

On Sun, Jun 21, 2009 at 4:20 AM, Simon Bull<waysoftheearth at yahoo.com.au> wrote:
>
> One possible solution to my issue would be something like this:
>
> ??? /some text/???????? -->? <font style="italic">some text</font>
> ??? -s-o-m-e-t-e-x-t-?? -->? <font style="struckout">some text</font>
> ??? _some text_???????? -->? <font style="underline">some text</font>
> ??? *some text*???????? -->? <font style="bold">some text</font>
>
> I anticipate that there probably won't be much appetite for changing the
> markdown tool, so I intend to have a go at implementing the above for my own
> "local" markdown (with approximately zero knowledge of Python).

Python-Markdown [1] (not Markdown2) recently released version 2.0 in
which most of the code has been refactored. The thing about
Python-Markdown (as opposed to any other implementation AFAIK) is that
it is very easy to alter the syntax to your liking via the extension
API. You can find the docs here:

http://gitorious.org/python-markdown/mainline/blobs/master/docs/writing_extensions.txt

or here (but it looks like the wiki is having some spam issues):

http://www.freewisdom.org/projects/python-markdown/Writing_Extensions&version=000011

I'd suggest replacing/adding your own "InlinePatterns" to alter the
existing emphasis and strong patterns. If you need any help, feel free
to ask.

[1]: http://pypi.python.org/pypi/Markdown

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

From waysoftheearth at yahoo.com.au  Mon Jun 22 00:02:40 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Mon, 22 Jun 2009 14:02:40 +1000
Subject: Query about emphasis
In-Reply-To: <e5d795bb0906212014u5df0b8e1t3262b0f85efbea8@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
	<e5d795bb0906212014u5df0b8e1t3262b0f85efbea8@mail.gmail.com>
Message-ID: <7a70dba0906212102t7c662634r9b1c808f6268399a@mail.gmail.com>

Okay, thanks for the pointers -- I will see how far I get.

So what is the relationship (if any) between the Python-Markdown[1] and the
Markdown2[2] implementations?

Is this list primarily oriented toward discussion of one over the other, or
open to more general discussion?

Simon

[1] http://pypi.python.org/pypi/Markdown
[2] http://pypi.python.org/pypi/markdown2



On Mon, Jun 22, 2009 at 1:14 PM, Waylan Limberg <waylan at gmail.com> wrote:

> On Sun, Jun 21, 2009 at 4:20 AM, Simon Bull<waysoftheearth at yahoo.com.au>
> wrote:
> >
> > One possible solution to my issue would be something like this:
> >
> >     /some text/         -->  <font style="italic">some text</font>
> >     -s-o-m-e-t-e-x-t-   -->  <font style="struckout">some text</font>
> >     _some text_         -->  <font style="underline">some text</font>
> >     *some text*         -->  <font style="bold">some text</font>
> >
> > I anticipate that there probably won't be much appetite for changing the
> > markdown tool, so I intend to have a go at implementing the above for my
> own
> > "local" markdown (with approximately zero knowledge of Python).
>
> Python-Markdown [1] (not Markdown2) recently released version 2.0 in
> which most of the code has been refactored. The thing about
> Python-Markdown (as opposed to any other implementation AFAIK) is that
> it is very easy to alter the syntax to your liking via the extension
> API. You can find the docs here:
>
>
> http://gitorious.org/python-markdown/mainline/blobs/master/docs/writing_extensions.txt
>
> or here (but it looks like the wiki is having some spam issues):
>
>
> http://www.freewisdom.org/projects/python-markdown/Writing_Extensions&version=000011
>
> I'd suggest replacing/adding your own "InlinePatterns" to alter the
> existing emphasis and strong patterns. If you need any help, feel free
> to ask.
>
> [1]: http://pypi.python.org/pypi/Markdown
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090622/861b638b/attachment.html>

From waylan at gmail.com  Mon Jun 22 08:55:15 2009
From: waylan at gmail.com (Waylan Limberg)
Date: Mon, 22 Jun 2009 08:55:15 -0400
Subject: Query about emphasis
In-Reply-To: <7a70dba0906212102t7c662634r9b1c808f6268399a@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com> 
	<e5d795bb0906212014u5df0b8e1t3262b0f85efbea8@mail.gmail.com> 
	<7a70dba0906212102t7c662634r9b1c808f6268399a@mail.gmail.com>
Message-ID: <e5d795bb0906220555q64d9e060g8563d5ce656e43a2@mail.gmail.com>

On Mon, Jun 22, 2009 at 12:02 AM, Simon Bull<waysoftheearth at yahoo.com.au> wrote:
> Okay, thanks for the pointers -- I will see how far I get.
>
> So what is the relationship (if any) between the Python-Markdown[1] and the
> Markdown2[2] implementations?

Other than the fact that they are both markdown implementations and
both are written in python - none. Python Markdown has been around a
lot longer and has an extensive extension api. Markdown2 is intended
to be a direct port markdown.pl and is relatively young. To my
knowledge they do not share any code and are maintained by different
individuals.

> Is this list primarily oriented toward discussion of one over the other, or
> open to more general discussion?

This list was (I believe) originally intended for discussion of the
perl implementation (the first - created by John Gruber) and has
expanded to be a general discussion forum for any and all
implementations.

If you would like to discuss specifics or code regarding the
Python-Markdown implementation, we have our own list here:

http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

From waysoftheearth at yahoo.com.au  Mon Jun 22 09:43:10 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Mon, 22 Jun 2009 23:43:10 +1000
Subject: Query about emphasis
In-Reply-To: <e5d795bb0906220555q64d9e060g8563d5ce656e43a2@mail.gmail.com>
References: <7a70dba0906210120n2bcfa828k74faa703c64450c2@mail.gmail.com>
	<e5d795bb0906212014u5df0b8e1t3262b0f85efbea8@mail.gmail.com>
	<7a70dba0906212102t7c662634r9b1c808f6268399a@mail.gmail.com>
	<e5d795bb0906220555q64d9e060g8563d5ce656e43a2@mail.gmail.com>
Message-ID: <7a70dba0906220643x198d2863mcc4b1f30007f87ae@mail.gmail.com>

Okay, thanks for the clarification.


On Mon, Jun 22, 2009 at 10:55 PM, Waylan Limberg <waylan at gmail.com> wrote:

> On Mon, Jun 22, 2009 at 12:02 AM, Simon Bull<waysoftheearth at yahoo.com.au>
> wrote:
> > Okay, thanks for the pointers -- I will see how far I get.
> >
> > So what is the relationship (if any) between the Python-Markdown[1] and
> the
> > Markdown2[2] implementations?
>
> Other than the fact that they are both markdown implementations and
> both are written in python - none. Python Markdown has been around a
> lot longer and has an extensive extension api. Markdown2 is intended
> to be a direct port markdown.pl and is relatively young. To my
> knowledge they do not share any code and are maintained by different
> individuals.
>
> > Is this list primarily oriented toward discussion of one over the other,
> or
> > open to more general discussion?
>
> This list was (I believe) originally intended for discussion of the
> perl implementation (the first - created by John Gruber) and has
> expanded to be a general discussion forum for any and all
> implementations.
>
> If you would like to discuss specifics or code regarding the
> Python-Markdown implementation, we have our own list here:
>
>
> http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090622/6c678cf6/attachment.html>

From waysoftheearth at yahoo.com.au  Tue Jun 23 00:01:27 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Tue, 23 Jun 2009 14:01:27 +1000
Subject: More continuing text for tables
Message-ID: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>

Hello List,


While translating documents in markdown, I've noticed that it is often
necessary to continue table cell text on the following line, especially when
limited to a narrow column, and especially in table headers.  Unfortunately,
this is impossible with the existing table syntax, which interprets each new
line as a new table row.

I see that David Wheeler proposed a syntax for a text continuation in tables
based on database outputs (see
http://www.justatheory.com/computers/markup/markdown-table-rfc.html, and
also recent discussion on this list).

Text continuation seems to me to be a desirable addition to markdown, and
DW's proposal looks very encouraging.  The outstanding arguments I could
find against his proposed ':' cell separator are:

1. Not usable as described with proportional fonts,
2. Cannot distinguish between ':' as a separator and ':' as cell content.


I'd like to offer the following thoughts with a view to hopefully resolving
these issues.


Use With Proportional Fonts
---------------------------

The ':' syntax could work exactly as per the existing '|' cell separator,
such that the ':' cell separator be *required* on the right of each column
rather than optional.  The last column would continue to be optional, as per
the existing '|' cell syntax.

Thus, text may be continued over any number of lines in a table body, like
this;


   |    Col A    |   Col B  |  Col C
---+-------------+----------+---------
 1 |      A1     |    B1    |    C1
   : a2 contains :  b2      :  c2
   : some long & :   b2     :   c2
   : interesting :    b2    :    c2
 2 | commentary  |     B2   |     C2
 3 |      A3     |    B3    |    C3


Text may also be continued over any number of lines in a table header, like
this;


   : This is   :         :
   : Continued :         :
   : for Ages  :         :
   | and Ages! |  Col B  |  Col C
---+-----------+---------+---------
 1 |     A1    |   B1    |    C1
 2 |     A2    |   B2    |    C2


This works exactly the way pipe '|' currently work with both proportional
and non-proportional fonts.


The question raised by the second example is how should markdown parsers
distinguish between a table which begins with text continuation markers, and
a list definition?

I believe this can be resolved by looking ahead to the following lines of
the document.  Whether a table's compulsory '---' header/body separator line
is encountered before a blank line should be enough to establish context.


Distinguishing Cell Separator from Cell Content
-----------------------------------------------

The existing pipe separator syntax must also have this same issue, the
difference (presumably) being that;

    * The colon is used more commonly in content than the pipe, and,
    * ':' is markdown syntax denoting a definition list.


1. The simplest, but most restrictive, option is to simply not support
colons within cell content. All colons, in the context of tables, are
therefore cell delimiters.

2. A less restrictive option is to require all colons within table cell
content to be formally escaped, thus '\:'.  While this works technically, it
has the disadvantage of polluting the source text.

3. An alternative option is to define the colon cell separator more exactly,
such that in the context of a table;

    * Any colon encountered with leading or trailing text (e.g., 'text:' or
':text') is not a cell separator.
    * Any colon encountered exactly one or two characters after a colon
(E.g., '::' or ': :') is not a cell separator.  Thus, colons denoting cell
separators must always be at least two characters apart.  This implies that
no column (excepting the first and last) can be a single character wide.


I believe that option 3 has the most appeal since it does not pollute the
source text at all, and only forces the author to create "neat" tables in
order to work.

In any case, it seems likely that the use of colons within table content
would be rare compared to the use of text continuing across lines.
Therefore, the inconvenience caused by any of the suggested options may be
acceptable to an author who really just wants text continuing across lines!


Just a few thoughts...

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090623/6f880728/attachment.html>

From michel.fortin at michelf.com  Tue Jun 23 14:38:27 2009
From: michel.fortin at michelf.com (Michel Fortin)
Date: Tue, 23 Jun 2009 14:38:27 -0400
Subject: More continuing text for tables
In-Reply-To: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
Message-ID: <1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>

Le 2009-06-23 ? 0:01, Simon Bull a ?crit :

> Thus, text may be continued over any number of lines in a table  
> body, like
> this;
>
>
>   |    Col A    |   Col B  |  Col C
> ---+-------------+----------+---------
> 1 |      A1     |    B1    |    C1
>   : a2 contains :  b2      :  c2
>   : some long & :   b2     :   c2
>   : interesting :    b2    :    c2
> 2 | commentary  |     B2   |     C2
> 3 |      A3     |    B3    |    C3


Are you sure this syntax is so intuitive? I was certain (for about 5  
minutes) that you meant the colons to continue the cell from the  
previous line, not start a new cell, despite the weird result. What  
David Wheeler proposed seem to follow my interpretation. Basically,  
here's what I saw:

   |    Col A    |  Col B   |  Col C
==+=============+==========+=========
1 |      A1     |    B1    |    C1
   | a2 contains |  b2      |  c2
   | some long & |   b2     |   c2
   | interesting |    b2    |    c2
--+-------------+----------+---------
2 | commentary  |     B2   |     C2
--+-------------+----------+---------
3 |      A3     |    B3    |    C3

And here's what I believe you meant:

   |    Col A    |  Col B   |  Col C
==+=============+==========+=========
1 |      A1     |    B1    |    C1
--+-------------+----------+---------
   | a2 contains |  b2      |  c2
   | some long & |   b2     |   c2
   | interesting |    b2    |    c2
2 | commentary  |     B2   |     C2
--+-------------+----------+---------
3 |      A3     |    B3    |    C3

Which makes me believe my syntax above using explicit line separators  
may be better, even though it's much more verbose.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




From waylan at gmail.com  Tue Jun 23 16:35:03 2009
From: waylan at gmail.com (Waylan Limberg)
Date: Tue, 23 Jun 2009 16:35:03 -0400
Subject: More continuing text for tables
In-Reply-To: <1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com> 
	<1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>
Message-ID: <e5d795bb0906231335u75663ccdx51111f609e3d5ff7@mail.gmail.com>

On Tue, Jun 23, 2009 at 2:38 PM, Michel Fortin<michel.fortin at michelf.com> wrote:
[snip]
> Are you sure this syntax is so intuitive? I was certain (for about 5
> minutes) that you meant the colons to continue the cell from the previous
> line, not start a new cell, despite the weird result. What David Wheeler
> proposed seem to follow my interpretation. Basically, here's what I saw:
>
[snip]
>
> And here's what I believe you meant:
>
[snip]
>
> Which makes me believe my syntax above using explicit line separators may be
> better, even though it's much more verbose.

Wow, I made the exact same mistake, except that I never caught on to
what was really indented. In any event, the more verbose syntax
proposed by Michael seems like the only reasonable alternative to me
as well.

That said, I am leaning more toward the opinion that anything more
complex that can already be done should be left to raw html. But I've
already explained my position on that before.


-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

From david at kineticode.com  Tue Jun 23 17:01:19 2009
From: david at kineticode.com (David E. Wheeler)
Date: Tue, 23 Jun 2009 14:01:19 -0700
Subject: More continuing text for tables
In-Reply-To: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
Message-ID: <0E4A8854-3F4C-473E-B67D-A856BD2E97B8@kineticode.com>

On Jun 22, 2009, at 9:01 PM, Simon Bull wrote:

>     * The colon is used more commonly in content than the pipe, and,
>     * ':' is markdown syntax denoting a definition list.

Actually, it's in used for a definition list in MultiMarkdown.  
Markdown does not support definition lists. I have a [related proposal] 
[] for definition lists that's identical to what MM does, except that  
it uses ~ instead of :, both because it's easier to see as a bullet in  
many fonts, and because it's not all that common.

[related proposal]: http://justatheory.com/computers/markup/modest-markdown-proposal.html

Best,

David

From david at kineticode.com  Tue Jun 23 17:04:44 2009
From: david at kineticode.com (David E. Wheeler)
Date: Tue, 23 Jun 2009 14:04:44 -0700
Subject: More continuing text for tables
In-Reply-To: <1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
	<1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>
Message-ID: <9311D7B9-AA20-4628-B12D-431B9E59AA64@kineticode.com>

On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote:

> And here's what I believe you meant:
>
>  |    Col A    |  Col B   |  Col C
> ==+=============+==========+=========
> 1 |      A1     |    B1    |    C1
> --+-------------+----------+---------
>  | a2 contains |  b2      |  c2
>  | some long & |   b2     |   c2
>  | interesting |    b2    |    c2
> 2 | commentary  |     B2   |     C2
> --+-------------+----------+---------
> 3 |      A3     |    B3    |    C3
>
> Which makes me believe my syntax above using explicit line  
> separators may be better, even though it's much more verbose.

Yes, Simon's was not quite right. It should be:

|    Col A    |   Col B  |  Col C
+-------------+----------+---------
|      A1     |    B1    |    C1
| a2 contains |  b2      |  c2
: some long & :   b2     :   c2
: interesting :    b2    :    c2
: commentary  :     B2   :     C2
|      A3     |    B3    |    C3

See also pgsql.

Best,

David

From waysoftheearth at yahoo.com.au  Tue Jun 23 21:43:18 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Wed, 24 Jun 2009 11:43:18 +1000
Subject: More continuing text for tables
In-Reply-To: <9311D7B9-AA20-4628-B12D-431B9E59AA64@kineticode.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
	<1BEE6DA5-CBCF-4DDD-8AE6-3D5ECEB22EF9@michelf.com>
	<9311D7B9-AA20-4628-B12D-431B9E59AA64@kineticode.com>
Message-ID: <7a70dba0906231843s7d6791c9x5c27413c4f28a9a3@mail.gmail.com>

My apologies, I didn't read David's post correctly.  After looking at it
more closely, I agree with the previous posts; a leading pipe followed
vertically by trailing colons is much better than the other way around, so
it should have looked like this:

    Col A    |   Col B  |  Col C
-------------+----------+---------
      A1     |    B1    |    C1
 a2 contains |  b2      |  c2
 some long & :   b2     :   c2
 interesting :    b2    :    c2
 commentary  :     B2   :     C2
      A3     |    B3    |    C3


Explicit row markers do _work_, but they are too verbose for my liking.
They are more work to write, and don't read as cleanly.  The colon syntax
_works_ too, and it is cleaner, and I think having a source document which
is natural to write, and easy to read is important.

All that aside, it is support for the continued text *feature* that I am
most interested in.  If I have to live with explicit line breaks, I guess I
will.  But it would seem a shame, given the alternative.


Regarding David's [related proposal][] for the use of tildes '~' for
definition lists, I was also going to suggest adding tildes to support
definition lists within tables, but I backed off from that in my original
post so as not to cloud the central issue; continued text in tables.

However, I strongly agree that the tilde could be used in for definition
lists, thereby removing the ambiguity between colons used as cell delimiters
and those used in definition lists.


I will have to have a look at multimarkdown too :)

Thanks to all who replied,

Simon

[related proposal]:
http://justatheory.com/computers/markup/modest-markdown-proposal.html




On Wed, Jun 24, 2009 at 7:04 AM, David E. Wheeler <david at kineticode.com>wrote:

> On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote:
>
>  And here's what I believe you meant:
>>
>>  |    Col A    |  Col B   |  Col C
>> ==+=============+==========+=========
>> 1 |      A1     |    B1    |    C1
>> --+-------------+----------+---------
>>  | a2 contains |  b2      |  c2
>>  | some long & |   b2     |   c2
>>  | interesting |    b2    |    c2
>> 2 | commentary  |     B2   |     C2
>> --+-------------+----------+---------
>> 3 |      A3     |    B3    |    C3
>>
>> Which makes me believe my syntax above using explicit line separators may
>> be better, even though it's much more verbose.
>>
>
> Yes, Simon's was not quite right. It should be:
>
> |    Col A    |   Col B  |  Col C
> +-------------+----------+---------
> |      A1     |    B1    |    C1
> | a2 contains |  b2      |  c2
> : some long & :   b2     :   c2
> : interesting :    b2    :    c2
> : commentary  :     B2   :     C2
> |      A3     |    B3    |    C3
>
> See also pgsql.
>
> Best,
>
> David
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090624/9a20e557/attachment.html>

From waylan at gmail.com  Tue Jun 23 21:45:04 2009
From: waylan at gmail.com (Waylan Limberg)
Date: Tue, 23 Jun 2009 21:45:04 -0400
Subject: More continuing text for tables
In-Reply-To: <0E4A8854-3F4C-473E-B67D-A856BD2E97B8@kineticode.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com> 
	<0E4A8854-3F4C-473E-B67D-A856BD2E97B8@kineticode.com>
Message-ID: <e5d795bb0906231845w6a725c13we8c0ed6ae50885b1@mail.gmail.com>

On Tue, Jun 23, 2009 at 5:01 PM, David E. Wheeler<david at kineticode.com> wrote:
> On Jun 22, 2009, at 9:01 PM, Simon Bull wrote:
>
>> ? ?* The colon is used more commonly in content than the pipe, and,
>> ? ?* ':' is markdown syntax denoting a definition list.
>
> Actually, it's in used for a definition list in MultiMarkdown. Markdown does
> not support definition lists. I have a [related proposal][] for definition
> lists that's identical to what MM does, except that it uses ~ instead of :,
> both because it's easier to see as a bullet in many fonts, and because it's
> not all that common.

Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3]
all support definition lists using  the colon as well. And that's only
the ones I'm familiar with. There may be others. The point is, I think
this is an established enough syntax used by enough people who have
written enough documents, that it would be a little to painful to
change now. Of course, if anyone wanted to introduce an alternate
syntax using the tilde, they certainly can. However, I don't believe
your proposal mitigates Simon's concern regarding overuse of the
colon. In fact, it would seem reasonable to expect that the very
implementations which correctly support definition lists (using
colons) would be the first to implement any new alternate table
syntax, whether it uses colons or not.

[1]: http://www.michelf.com/projects/php-markdown/extra/#def-list
[2]: http://www.freewisdom.org/projects/python-markdown/Definition_Lists
[3]: http://johnmacfarlane.net/pandoc/README.html#definition-lists


-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

From waylan at gmail.com  Tue Jun 23 21:48:44 2009
From: waylan at gmail.com (Waylan Limberg)
Date: Tue, 23 Jun 2009 21:48:44 -0400
Subject: More continuing text for tables
In-Reply-To: <e5d795bb0906231845w6a725c13we8c0ed6ae50885b1@mail.gmail.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com> 
	<0E4A8854-3F4C-473E-B67D-A856BD2E97B8@kineticode.com>
	<e5d795bb0906231845w6a725c13we8c0ed6ae50885b1@mail.gmail.com>
Message-ID: <e5d795bb0906231848y33537080s95ece6f7fb2f54d6@mail.gmail.com>

On Tue, Jun 23, 2009 at 9:45 PM, Waylan Limberg<waylan at gmail.com> wrote:
[snip]
> colon. In fact, it would seem reasonable to expect that the very
> implementations which correctly support definition lists (using
> colons) would be the first to implement any new alternate table
> syntax, whether it uses colons or not.
>

Sorry, that was supposed to say "...which *currently* support
definition lists..."

Apologies for any confusion my fat fingers may have caused.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

From david at kineticode.com  Tue Jun 23 22:23:37 2009
From: david at kineticode.com (David E. Wheeler)
Date: Tue, 23 Jun 2009 19:23:37 -0700
Subject: More continuing text for tables
Message-ID: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>

On Jun 23, 2009, at 6:43 PM, Simon Bull wrote:

> Explicit row markers do _work_, but they are too verbose for my  
> liking.
> They are more work to write, and don't read as cleanly.  The colon  
> syntax
> _works_ too, and it is cleaner, and I think having a source document  
> which
> is natural to write, and easy to read is important.

+1, although sometimes, with really busy tables, they make things  
clearer.

> All that aside, it is support for the continued text *feature* that  
> I am
> most interested in.  If I have to live with explicit line breaks, I  
> guess I
> will.  But it would seem a shame, given the alternative.

I agree, but what I mean by "busy tables" is when you have a table  
with multicolumn cells *and* multirow rows. My blog entry has a decent  
example of this:

|               |            Grouping            ||
+---------------+---------------------------------+
| First Header  |  Second Header  |  Third Header |
+---------------+-----------------+---------------+
| Content       |           *Long Cell*          ||
: continued     :                                ::
: content       :                                ::
| Content       |    **Cell**     |          Cell |
: continued     :                 :               :
: content       :                 :               :

| New section   |      More       |          Data |
| And more      |             And more           ||
  [Prototype table]

It starts to get a little confusing in this case, so I'd like, for  
more complicated tables, to alternatively be able to designate rows  
like so:

|               |            Grouping            ||
+===============+=================================+
| First Header  |  Second Header  |  Third Header |
+===============+=================================+
| Content       |           *Long Cell*          ||
: continued     :                                ::
: content       :                                ::
+---------------+---------------------------------+
| Content       |    **Cell**     |          Cell |
: continued     :                 :               :
: content       :                 :               :
+---------------+---------------------------------+

+---------------+---------------------------------+
| New section   |      More       |          Data |
+---------------+---------------------------------+
| And more      |             And more           ||
+---------------+---------------------------------+
  [Prototype table]

You can distinguish the one style from the other by the use of =s in  
the header instead of -s.

> However, I strongly agree that the tilde could be used in for  
> definition
> lists, thereby removing the ambiguity between colons used as cell  
> delimiters
> and those used in definition lists.

Thanks! They stand out better, too, in most fonts.

Best,

David

From david at kineticode.com  Tue Jun 23 22:25:33 2009
From: david at kineticode.com (David E. Wheeler)
Date: Tue, 23 Jun 2009 19:25:33 -0700
Subject: More continuing text for tables
In-Reply-To: <e5d795bb0906231845w6a725c13we8c0ed6ae50885b1@mail.gmail.com>
References: <7a70dba0906222101y22fa747bh986be99ce3fd8c30@mail.gmail.com>
	<0E4A8854-3F4C-473E-B67D-A856BD2E97B8@kineticode.com>
	<e5d795bb0906231845w6a725c13we8c0ed6ae50885b1@mail.gmail.com>
Message-ID: <F952E849-FD85-409C-AA8F-01E86DBA8AAA@kineticode.com>

On Jun 23, 2009, at 6:45 PM, Waylan Limberg wrote:

> Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3]
> all support definition lists using  the colon as well. And that's only
> the ones I'm familiar with. There may be others. The point is, I think
> this is an established enough syntax used by enough people who have
> written enough documents, that it would be a little to painful to
> change now.

I actually submitted a patch to MultiMarkdown to allow ~ as an  
alternative, for backwards compatibility.

> However, I don't believe
> your proposal mitigates Simon's concern regarding overuse of the
> colon. In fact, it would seem reasonable to expect that the very
> implementations which correctly support definition lists (using
> colons) would be the first to implement any new alternate table
> syntax, whether it uses colons or not.

If the tilde were to be formally adopted by core markdown, the colon  
would not be overused for this purpose. And I'm going on psql as prior  
art in suggesting the colon for continued lines.

Best,

David

From waysoftheearth at yahoo.com.au  Wed Jun 24 01:24:54 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Wed, 24 Jun 2009 15:24:54 +1000
Subject: More continuing text for tables
In-Reply-To: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
Message-ID: <7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>

Personally, I would prefer to use exactly one table syntax, so long as it
_works_.


Using one pipe per col to span is okay for small number of columns to span,
though it doesn't scale elegantly, as in the following example;

   |  This cell spans 9 cols, and therefore has 9 pipes   |||||||||
   | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
---+------+------+------+------+------+------+------+------+------+
 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |  H1  |  I1  |


An alternative (or additional) syntax option might be to use an alternative
cell separator when colspan is required.  '!' comes to mind, since it looks
almost exactly like a '|' in most fonts. '[' or ']' are other
possibilities.

I don't mind whether we use the leading or trailing cell-delimiter for this,
but in my examples below, I mostly use a leading cell delimiter.

The disadvantage of using another type of cell delimiter is that it
introduces additional table framework into our text.

However, the advantage is that by default a '!' cell separator could
indicate colspan=2, which would likely be the most common case.  So, for
colspan=2, no additional pollution of the text would be required. E.g.,

   | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
---+------+------+------+------+------+------+------+------+------+
 1 |  A1  |  B1  !  C1 and D1  |  E1  !  F1 and G1  |  H1  |  I1  |
 2 |  A2  |  B2  |  C1  !  D2 and E2  |  F2  !  G2 and H2  |  I1  |


Where a colspan greater than 2 is required, metadata must unfortunately be
introduced.  For this I would like to suggest two alternatives;

The first suggestion is similar to David's proposal except that it uses a
number of  underscores to indicate of the number of columns a cell should
span, such that colspan = number of underscores +2.  In the most common
case, colspan=2, no underscores are required.  Colspan=3 requires one
underscore, colspan=4 requires two underscores, and so on.

If I *must* use metadata characters, then I prefer underscores because they
at least "look like" part of the table frame (imagine it as part of a line
between two rows).  For example;

   | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I
---+-------+-------+-------+-------+-------+-------+-------+-------+-------
 1 |   A1  |   B1  |   C1  |   D1  |   E1  |   F1  |   G1  |   H1  |   I1
 2 !_    colspan three     !  colspan two  !__        colspan four
 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3


Overall, this approach requires one fewer metadata character in every
colspanned cell.


The second suggestion is to use '[' as a leading cell separator, or ']' as a
trailing cell-separator, where colspan is required.  This could be followed,
or led, by a number x such that colspan = x.  A number need not be supplied
where x == 2.

For example;

   | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I
---+-------+-------+-------+-------+-------+-------+-------+-------+-------
 1 |   A1  |   B1  |   C1  |   D1  |   E1  |   F1  |   G1  |   H1  |   I1
 2 [3    colspan three     [  colspan two  [4        colspan four
 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3

would be exactly equivalent to

   | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I |
---+-------+-------+-------+-------+-------+-------+-------+-------+-------+
 1 |   A1  |   B1  |   C1  |   D1  |   E1  |   F1  |   G1  |   H1  |   I1  |
 2 |     colspan three    3]  colspan two  ]         colspan four         4]
 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3  |


This approach requires fewer metadata characters overall, but I prefer the
first suggestion (underscores) because it looks nicer, and reads more
easily.



Simon

On Wed, Jun 24, 2009 at 12:23 PM, David E. Wheeler <david at kineticode.com>wrote:

> On Jun 23, 2009, at 6:43 PM, Simon Bull wrote:
>
>  Explicit row markers do _work_, but they are too verbose for my liking.
>> They are more work to write, and don't read as cleanly.  The colon syntax
>> _works_ too, and it is cleaner, and I think having a source document which
>> is natural to write, and easy to read is important.
>>
>
> +1, although sometimes, with really busy tables, they make things clearer.
>
>  All that aside, it is support for the continued text *feature* that I am
>> most interested in.  If I have to live with explicit line breaks, I guess
>> I
>> will.  But it would seem a shame, given the alternative.
>>
>
> I agree, but what I mean by "busy tables" is when you have a table with
> multicolumn cells *and* multirow rows. My blog entry has a decent example of
> this:
>
> |               |            Grouping            ||
> +---------------+---------------------------------+
> | First Header  |  Second Header  |  Third Header |
> +---------------+-----------------+---------------+
> | Content       |           *Long Cell*          ||
> : continued     :                                ::
> : content       :                                ::
> | Content       |    **Cell**     |          Cell |
> : continued     :                 :               :
> : content       :                 :               :
>
> | New section   |      More       |          Data |
> | And more      |             And more           ||
>  [Prototype table]
>
> It starts to get a little confusing in this case, so I'd like, for more
> complicated tables, to alternatively be able to designate rows like so:
>
> |               |            Grouping            ||
> +===============+=================================+
> | First Header  |  Second Header  |  Third Header |
> +===============+=================================+
> | Content       |           *Long Cell*          ||
> : continued     :                                ::
> : content       :                                ::
> +---------------+---------------------------------+
> | Content       |    **Cell**     |          Cell |
> : continued     :                 :               :
> : content       :                 :               :
> +---------------+---------------------------------+
>
> +---------------+---------------------------------+
> | New section   |      More       |          Data |
> +---------------+---------------------------------+
> | And more      |             And more           ||
> +---------------+---------------------------------+
>  [Prototype table]
>
> You can distinguish the one style from the other by the use of =s in the
> header instead of -s.
>
>  However, I strongly agree that the tilde could be used in for definition
>> lists, thereby removing the ambiguity between colons used as cell
>> delimiters
>> and those used in definition lists.
>>
>
> Thanks! They stand out better, too, in most fonts.
>
> Best,
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090624/325d9930/attachment.htm>

From david at kineticode.com  Wed Jun 24 13:05:01 2009
From: david at kineticode.com (David E. Wheeler)
Date: Wed, 24 Jun 2009 10:05:01 -0700
Subject: More continuing text for tables
In-Reply-To: <7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
Message-ID: <D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>

On Jun 23, 2009, at 10:24 PM, Simon Bull wrote:

> Personally, I would prefer to use exactly one table syntax, so long  
> as it
> _works_.

Yeah, that would be my preference, as well, where "_works_" eq "is  
legible as plain text and parses properly."

> Using one pipe per col to span is okay for small number of columns  
> to span,
> though it doesn't scale elegantly, as in the following example;
>
>   |  This cell spans 9 cols, and therefore has 9 pipes   |||||||||
>   | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
> ---+------+------+------+------+------+------+------+------+------+
> 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |  H1  |  I1  |

Yeah, point taken, although that'd be a pretty rare occurrence.

> An alternative (or additional) syntax option might be to use an  
> alternative
> cell separator when colspan is required.  '!' comes to mind, since  
> it looks
> almost exactly like a '|' in most fonts. '[' or ']' are other
> possibilities.

Well, ! is pretty common in text, and [ and ] are already used for  
links.

> However, the advantage is that by default a '!' cell separator could
> indicate colspan=2, which would likely be the most common case.  So,  
> for
> colspan=2, no additional pollution of the text would be required.  
> E.g.,
>
>   | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
> ---+------+------+------+------+------+------+------+------+------+
> 1 |  A1  |  B1  !  C1 and D1  |  E1  !  F1 and G1  |  H1  |  I1  |
> 2 |  A2  |  B2  |  C1  !  D2 and E2  |  F2  !  G2 and H2  |  I1  |

That's not very intuitive to me.

> Where a colspan greater than 2 is required, metadata must  
> unfortunately be
> introduced.  For this I would like to suggest two alternatives;
>
> The first suggestion is similar to David's proposal except that it  
> uses a
> number of  underscores to indicate of the number of columns a cell  
> should
> span, such that colspan = number of underscores +2.  In the most  
> common
> case, colspan=2, no underscores are required.  Colspan=3 requires one
> underscore, colspan=4 requires two underscores, and so on.

3 == 1, 4 == 2? Ick.

> If I *must* use metadata characters, then I prefer underscores  
> because they
> at least "look like" part of the table frame (imagine it as part of  
> a line
> between two rows).  For example;
>
>   | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H |  
> Col I
> ---+-------+-------+-------+-------+-------+-------+-------+------- 
> +-------
> 1 |   A1  |   B1  |   C1  |   D1  |   E1  |   F1  |   G1  |   H1   
> |   I1
> 2 !_    colspan three     !  colspan two  !__        colspan four
> 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3   
> |   I3
>
>
> Overall, this approach requires one fewer metadata character in every
> colspanned cell.

But it provides no meaning to the reader of the plain text. It just  
looks like a pasto or something. I'm opposed to adding characters with  
no semantic meaning.

> The second suggestion is to use '[' as a leading cell separator, or  
> ']' as a
> trailing cell-separator, where colspan is required.  This could be  
> followed,
> or led, by a number x such that colspan = x.  A number need not be  
> supplied
> where x == 2.

Um, no. Same problem.

> This approach requires fewer metadata characters overall, but I  
> prefer the
> first suggestion (underscores) because it looks nicer, and reads more
> easily.

I don't like either one, because they're very poor communicators of  
semantic meaning to the reader of the plain text version. Your  
original example with nine merge columns is much nicer-looking to my  
eye. And it's what MultiMarkdown already does, IIRC.

Best,

David


From waysoftheearth at yahoo.com.au  Wed Jun 24 19:27:49 2009
From: waysoftheearth at yahoo.com.au (Simon Bull)
Date: Thu, 25 Jun 2009 09:27:49 +1000
Subject: More continuing text for tables
In-Reply-To: <D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
	<D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
Message-ID: <7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>

Okay, thanks for your input, David.

Tables with lots of narrow columns are not so rare they can be dismissed;
they are useful for matrices of numbers, for example.

How about an (entirely optional) addition to the existing multimarkdown pipe
syntax, specifically for cells which span many cols?  A number followed
immediately by a pipe would be taken as the colspan.

So this;

   | This cell spans 7 cols, and has less spa |||||||
   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
---+------+------+------+------+------+------+------+
 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |

would be exactly equivalent to this;

   |   This cell spans 7 cols, and has more space  7|
   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
---+------+------+------+------+------+------+------+
 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |

It contains 1 ugly metadata character, true.  It is a matter of personal
taste as to whether you find 6 additional pipes or 1 digit more intrusive,
so why not provide authors with the choice?  The advantage of the digit
meta-character, of course, is the additional space in the cell to write
content.


The real problem is that *neither* of these options is entirely natural to
either the author or the reader.


Thinking some more, I realise that neither metadata option is required at
all to parse a table row correctly when there is only a single colspan cell
in a row _if_ we have a distinct cell-delimiter which denotes a colspanning
cell.


The example above _could_ be rewritten like this;

   |  This cell spans 7 cols, and looks much nicer  !
   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
---+------+------+------+------+------+------+------+
 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |


Note the exclamation point as the last character on the first row.  I
acknowledge David's concern about the use of '!' for table structure, and
use it here only as an example.  Other punctuation marks could be
substituted.  Most, however, have the same issue -- that they are common in
text content.  This is not insurmountable.  A cell-delimiter character could
require a space either side, for example.

That aside, the example above looks more like what authors would naturally
write, and makes *much* cleaner reading than either meta-data option (to my
eyes, at least).


The introduction of a col-span indicating cell-delimiter means that *only*
the second and subsequent colspanning cells of any row require any metadata
to indicate span width.

Two (or more) colspanning cells per row would, presumably, be reasonably
rare.  When necessary, the author could use the existing multimarkdown
syntax for the narrower cells.


Simon



On Thu, Jun 25, 2009 at 3:05 AM, David E. Wheeler <david at kineticode.com>wrote:

> On Jun 23, 2009, at 10:24 PM, Simon Bull wrote:
>
>  Personally, I would prefer to use exactly one table syntax, so long as it
>> _works_.
>>
>
> Yeah, that would be my preference, as well, where "_works_" eq "is legible
> as plain text and parses properly."
>
>  Using one pipe per col to span is okay for small number of columns to
>> span,
>> though it doesn't scale elegantly, as in the following example;
>>
>>  |  This cell spans 9 cols, and therefore has 9 pipes   |||||||||
>>  | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
>> ---+------+------+------+------+------+------+------+------+------+
>> 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |  H1  |  I1  |
>>
>
> Yeah, point taken, although that'd be a pretty rare occurrence.
>
>  An alternative (or additional) syntax option might be to use an
>> alternative
>> cell separator when colspan is required.  '!' comes to mind, since it
>> looks
>> almost exactly like a '|' in most fonts. '[' or ']' are other
>> possibilities.
>>
>
> Well, ! is pretty common in text, and [ and ] are already used for links.
>
>  However, the advantage is that by default a '!' cell separator could
>> indicate colspan=2, which would likely be the most common case.  So, for
>> colspan=2, no additional pollution of the text would be required. E.g.,
>>
>>  | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI |
>> ---+------+------+------+------+------+------+------+------+------+
>> 1 |  A1  |  B1  !  C1 and D1  |  E1  !  F1 and G1  |  H1  |  I1  |
>> 2 |  A2  |  B2  |  C1  !  D2 and E2  |  F2  !  G2 and H2  |  I1  |
>>
>
> That's not very intuitive to me.
>
>  Where a colspan greater than 2 is required, metadata must unfortunately be
>> introduced.  For this I would like to suggest two alternatives;
>>
>> The first suggestion is similar to David's proposal except that it uses a
>> number of  underscores to indicate of the number of columns a cell should
>> span, such that colspan = number of underscores +2.  In the most common
>> case, colspan=2, no underscores are required.  Colspan=3 requires one
>> underscore, colspan=4 requires two underscores, and so on.
>>
>
> 3 == 1, 4 == 2? Ick.
>
>  If I *must* use metadata characters, then I prefer underscores because
>> they
>> at least "look like" part of the table frame (imagine it as part of a line
>> between two rows).  For example;
>>
>>  | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I
>>
>> ---+-------+-------+-------+-------+-------+-------+-------+-------+-------
>> 1 |   A1  |   B1  |   C1  |   D1  |   E1  |   F1  |   G1  |   H1  |   I1
>> 2 !_    colspan three     !  colspan two  !__        colspan four
>> 3 |   A3  |   B3  |   C3  |   D3  |   E3  |   F3  |   G3  |   H3  |   I3
>>
>>
>> Overall, this approach requires one fewer metadata character in every
>> colspanned cell.
>>
>
> But it provides no meaning to the reader of the plain text. It just looks
> like a pasto or something. I'm opposed to adding characters with no semantic
> meaning.
>
>  The second suggestion is to use '[' as a leading cell separator, or ']' as
>> a
>> trailing cell-separator, where colspan is required.  This could be
>> followed,
>> or led, by a number x such that colspan = x.  A number need not be
>> supplied
>> where x == 2.
>>
>
> Um, no. Same problem.
>
>  This approach requires fewer metadata characters overall, but I prefer the
>> first suggestion (underscores) because it looks nicer, and reads more
>> easily.
>>
>
> I don't like either one, because they're very poor communicators of
> semantic meaning to the reader of the plain text version. Your original
> example with nine merge columns is much nicer-looking to my eye. And it's
> what MultiMarkdown already does, IIRC.
>
>
> Best,
>
> David
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090625/69d34740/attachment.html>

From fletcher at fletcherpenney.net  Wed Jun 24 22:32:28 2009
From: fletcher at fletcherpenney.net (Fletcher T. Penney)
Date: Wed, 24 Jun 2009 22:32:28 -0400
Subject: More continuing text for tables
In-Reply-To: <7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>	<D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
	<7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
Message-ID: <4A42E1BC.5010700@fletcherpenney.net>

I can't say that I find this proposal to be perfect, but to me this was 
one of the more compelling emails in this thread.

I have been having my own internal conversation about how to rewrite the 
MMD table syntax.  My personal goals were to find a way to minimize the 
markup, make it more readable/less distracting, and hopefully easier to 
generate.


I started thinking seriously about how to rewrite the table syntax after 
reading about [elastic 
tabstops](http://nickgravgaard.com/elastictabstops/).  To me, these 
seemed to be the best way to implement tabs within text documents.

Then, it occurred to me that the only time I use tabs in MMD documents 
is at the beginning of a line, to indicate code blocks, or to indent 
lists.  I never use tabs within a line.

Yet tabs are inherently what I want to use to align columns of text in 
tables.

So I started looking into using tabs to separate columns within a table 
(i.e. replacing the | in the current MMD syntax).  If you used spaces 
before the tab, you could ensure that each row had the same 
column-widths (for sure with monospace font, and fairly tolerant for 
some variation with other fonts, but definitely not perfect).  If your 
editor used elastic tabstops, the plain text table would look right, and 
  it would be easily converted to an XHTML table.

It doesn't solve the colspan or rowspan issue.  My personal thoughts are:

* I like the idea of one colspan per row - more than that, and maybe you 
should just use HTML.  This would allow a simpler syntax.

* I am increasingly unconvinced that I should worry about rowspans, and 
require HTML for that.

* Every editor should support a standardized approach to elastic 
tabstops.  Too bad I can't make this happen.


Keeping in mind that my own goal for MMD is to provide an easy to write/ 
easy to read syntax for the 80-90% of tables that people write, at the 
expense of requiring HTML for the other group of complicate tables out 
there, I think there is hope for a table syntax built (almost?) entirely 
out of whitespace markers.


Thoughts?


F-




Simon Bull wrote:
> Okay, thanks for your input, David.
> 
> Tables with lots of narrow columns are not so rare they can be 
> dismissed; they are useful for matrices of numbers, for example.
> 
> How about an (entirely optional) addition to the existing multimarkdown 
> pipe syntax, specifically for cells which span many cols?  A number 
> followed immediately by a pipe would be taken as the colspan.
> 
> So this;
> 
>    | This cell spans 7 cols, and has less spa |||||||
>    | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
> ---+------+------+------+------+------+------+------+
>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |
> 
> would be exactly equivalent to this;
> 
>    |   This cell spans 7 cols, and has more space  7|
>    | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
> ---+------+------+------+------+------+------+------+
>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |
> 
> It contains 1 ugly metadata character, true.  It is a matter of personal 
> taste as to whether you find 6 additional pipes or 1 digit more 
> intrusive, so why not provide authors with the choice?  The advantage of 
> the digit meta-character, of course, is the additional space in the cell 
> to write content.
> 
> 
> The real problem is that *neither* of these options is entirely natural 
> to either the author or the reader.
> 
> 
> Thinking some more, I realise that neither metadata option is required 
> at all to parse a table row correctly when there is only a single 
> colspan cell in a row _if_ we have a distinct cell-delimiter which 
> denotes a colspanning cell.
> 

-- 
Fletcher T. Penney
fletcher at fletcherpenney.net

Every so often, I like to go to the window, look up, and smile for a
satellite picture.
	- Steven Wright
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3290 bytes
Desc: S/MIME Cryptographic Signature
Url : <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090624/0ac9d546/attachment-0001.bin>

From sgbotsford at gmail.com  Thu Jun 25 09:30:31 2009
From: sgbotsford at gmail.com (Sherwood Botsford)
Date: Thu, 25 Jun 2009 07:30:31 -0600
Subject: More continuing text for tables
In-Reply-To: <4A42E1BC.5010700@fletcherpenney.net>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
	<D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
	<7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
	<4A42E1BC.5010700@fletcherpenney.net>
Message-ID: <534004cc0906250630o52ab603ewded4dde209d4b72d@mail.gmail.com>

1.  Editing with non-elastic tab stops?  While Nick's idea is good, the
number of editors that support it is small.  Editors are a religious issue.
I doubt that people will switch editors in order to use MMD tables.
2.  I would like to see an option for a non-white character.  I've been
burned a few times by text processors that convert tabs to spaces.  This
will also ease the transition if you are changing the spec.
3.  For row spanning, the simplest syntax that is intuitive to me would be a
cell that has a single double-quote character.  Effectively saying 'same as
above'.
4.  Tables are one of the biggest reasons for using MMD. The ratio of tag
bytes to content bytes can be well over 1.  Matching tags is always a pain.
Even the clunkiest syntax proposed on this list has more merit than html
table tags.

My take: It aint broke.  Resist fixing it.

1.  Continue to support the pipe and multiple pipe syntax.  Cells that span
more than 3 columns are very rare, and many of these may be done with a
title instead, or be broken into multiple tables that are floated inline.

2.  Use quotes for row span.

On Wed, Jun 24, 2009 at 8:32 PM, Fletcher T. Penney <
fletcher at fletcherpenney.net> wrote:

> I can't say that I find this proposal to be perfect, but to me this was one
> of the more compelling emails in this thread.
>
> I have been having my own internal conversation about how to rewrite the
> MMD table syntax.  My personal goals were to find a way to minimize the
> markup, make it more readable/less distracting, and hopefully easier to
> generate.
>
>
> I started thinking seriously about how to rewrite the table syntax after
> reading about [elastic tabstops](http://nickgravgaard.com/elastictabstops/).
>  To me, these seemed to be the best way to implement tabs within text
> documents.
>
> Then, it occurred to me that the only time I use tabs in MMD documents is
> at the beginning of a line, to indicate code blocks, or to indent lists.  I
> never use tabs within a line.
>
> Yet tabs are inherently what I want to use to align columns of text in
> tables.
>
> So I started looking into using tabs to separate columns within a table
> (i.e. replacing the | in the current MMD syntax).  If you used spaces before
> the tab, you could ensure that each row had the same column-widths (for sure
> with monospace font, and fairly tolerant for some variation with other
> fonts, but definitely not perfect).  If your editor used elastic tabstops,
> the plain text table would look right, and  it would be easily converted to
> an XHTML table.
>
> It doesn't solve the colspan or rowspan issue.  My personal thoughts are:
>
> * I like the idea of one colspan per row - more than that, and maybe you
> should just use HTML.  This would allow a simpler syntax.
>
> * I am increasingly unconvinced that I should worry about rowspans, and
> require HTML for that.
>
> * Every editor should support a standardized approach to elastic tabstops.
>  Too bad I can't make this happen.
>
>
> Keeping in mind that my own goal for MMD is to provide an easy to write/
> easy to read syntax for the 80-90% of tables that people write, at the
> expense of requiring HTML for the other group of complicate tables out
> there, I think there is hope for a table syntax built (almost?) entirely out
> of whitespace markers.
>
>
> Thoughts?
>
>
> F-
>
>
>
>
>
> Simon Bull wrote:
>
>> Okay, thanks for your input, David.
>>
>> Tables with lots of narrow columns are not so rare they can be dismissed;
>> they are useful for matrices of numbers, for example.
>>
>> How about an (entirely optional) addition to the existing multimarkdown
>> pipe syntax, specifically for cells which span many cols?  A number followed
>> immediately by a pipe would be taken as the colspan.
>>
>> So this;
>>
>>   | This cell spans 7 cols, and has less spa |||||||
>>   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
>> ---+------+------+------+------+------+------+------+
>>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |
>>
>> would be exactly equivalent to this;
>>
>>   |   This cell spans 7 cols, and has more space  7|
>>   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
>> ---+------+------+------+------+------+------+------+
>>  1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |
>>
>> It contains 1 ugly metadata character, true.  It is a matter of personal
>> taste as to whether you find 6 additional pipes or 1 digit more intrusive,
>> so why not provide authors with the choice?  The advantage of the digit
>> meta-character, of course, is the additional space in the cell to write
>> content.
>>
>>
>> The real problem is that *neither* of these options is entirely natural to
>> either the author or the reader.
>>
>>
>> Thinking some more, I realise that neither metadata option is required at
>> all to parse a table row correctly when there is only a single colspan cell
>> in a row _if_ we have a distinct cell-delimiter which denotes a colspanning
>> cell.
>>
>>
> --
> Fletcher T. Penney
> fletcher at fletcherpenney.net
>
> Every so often, I like to go to the window, look up, and smile for a
> satellite picture.
>        - Steven Wright
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>


-- 
Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
[Note:  THREE s's in the web link]
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20090625/f583ed21/attachment.htm>

From david at kineticode.com  Thu Jun 25 12:23:09 2009
From: david at kineticode.com (David E. Wheeler)
Date: Thu, 25 Jun 2009 09:23:09 -0700
Subject: More continuing text for tables
In-Reply-To: <7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
	<D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
	<7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
Message-ID: <DD478994-3685-47D3-A24D-038F895FE769@kineticode.com>

On Jun 24, 2009, at 4:27 PM, Simon Bull wrote:

> Okay, thanks for your input, David.
>
> Tables with lots of narrow columns are not so rare they can be  
> dismissed;
> they are useful for matrices of numbers, for example.

Yeah, but merging a given row of them into one column is much less  
common.

> How about an (entirely optional) addition to the existing  
> multimarkdown pipe
> syntax, specifically for cells which span many cols?  A number  
> followed
> immediately by a pipe would be taken as the colspan.

Also not useful in the plain text. I'm all for affordances for the  
parser if their semantic value is apparent. Such is not the case here:  
the "7" is spurious and looks like a typo.

> It contains 1 ugly metadata character, true.  It is a matter of  
> personal
> taste as to whether you find 6 additional pipes or 1 digit more  
> intrusive,
> so why not provide authors with the choice?  The advantage of the  
> digit
> meta-character, of course, is the additional space in the cell to  
> write
> content.

It's not about obtrusiveness as much as meaning.

> The real problem is that *neither* of these options is entirely  
> natural to
> either the author or the reader.

Right.

> Thinking some more, I realise that neither metadata option is  
> required at
> all to parse a table row correctly when there is only a single  
> colspan cell
> in a row _if_ we have a distinct cell-delimiter which denotes a  
> colspanning
> cell.
>
>
> The example above _could_ be rewritten like this;
>
>   |  This cell spans 7 cols, and looks much nicer  !
>   | ColA | ColB | ColC | ColD | ColE | ColF | ColG |
> ---+------+------+------+------+------+------+------+
> 1 |  A1  |  B1  |  C1  |  D1  |  E1  |  F1  |  G1  |

Yes, better, though I might make both the right and left columns  
different.

> Note the exclamation point as the last character on the first row.  I
> acknowledge David's concern about the use of '!' for table  
> structure, and
> use it here only as an example.  Other punctuation marks could be
> substituted.  Most, however, have the same issue -- that they are  
> common in
> text content.  This is not insurmountable.  A cell-delimiter  
> character could
> require a space either side, for example.
>
> That aside, the example above looks more like what authors would  
> naturally
> write, and makes *much* cleaner reading than either meta-data option  
> (to my
> eyes, at least).

Agreed. But I'm not sure how many special cases we really want. They  
can be hard to remember when writing such a table. It seems to me that  
we should start with a design with *no* special cases and then see  
what cow paths develop.

> The introduction of a col-span indicating cell-delimiter means that  
> *only*
> the second and subsequent colspanning cells of any row require any  
> metadata
> to indicate span width.

I think I'd rather write it in HTML.

> Two (or more) colspanning cells per row would, presumably, be  
> reasonably
> rare.  When necessary, the author could use the existing multimarkdown
> syntax for the narrower cells.

If there is an existing syntax that works, why add the special case?

Best,

David


From david at kineticode.com  Thu Jun 25 12:27:19 2009
From: david at kineticode.com (David E. Wheeler)
Date: Thu, 25 Jun 2009 09:27:19 -0700
Subject: More continuing text for tables
In-Reply-To: <534004cc0906250630o52ab603ewded4dde209d4b72d@mail.gmail.com>
References: <47D8C8E0-1142-4D09-BA75-A32CA9DEFC53@kineticode.com>
	<7a70dba0906232224l698e70a9p85c5f7de04406dcb@mail.gmail.com>
	<D3A6333F-4760-4F37-A07A-68AD6BFA274D@kineticode.com>
	<7a70dba0906241627w701b5929q5b9d86142459b69d@mail.gmail.com>
	<4A42E1BC.5010700@fletcherpenney.net>
	<534004cc0906250630o52ab603ewded4dde209d4b72d@mail.gmail.com>
Message-ID: <290D4759-5667-41C1-A626-64D81F6E91C9@kineticode.com>

On Jun 25, 2009, at 6:30 AM, Sherwood Botsford wrote:

> 1.  Editing with non-elastic tab stops?  While Nick's idea is good,  
> the
> number of editors that support it is small.  Editors are a religious  
> issue.
> I doubt that people will switch editors in order to use MMD tables.

And it's not just editors: It's browsers, too. One of the great things  
about Markdown is that you can display the plain text anywhere and it  
will just work. Tabs are completely contrary to that, however. Elastic  
tabs may work as a nice convention in small teams writing source code,  
but tabs are evil for widely distributed code and documents.

> 2.  I would like to see an option for a non-white character.  I've  
> been
> burned a few times by text processors that convert tabs to spaces.   
> This
> will also ease the transition if you are changing the spec.

+1

> 3.  For row spanning, the simplest syntax that is intuitive to me  
> would be a
> cell that has a single double-quote character.  Effectively saying  
> 'same as
> above'.

I'm not sure that's visually distinctive enough. We really might just  
have to have row separators when merging rows in a cell. Or just use  
HTML, like Fletcher said.

> 4.  Tables are one of the biggest reasons for using MMD. The ratio  
> of tag
> bytes to content bytes can be well over 1.  Matching tags is always  
> a pain.
> Even the clunkiest syntax proposed on this list has more merit than  
> html
> table tags.
>
> My take: It aint broke.  Resist fixing it.

I agree. Most of the suggestions I've made were evolutions on the MMD  
syntax, and an attempt to eliminate non-semantic hinting characters.

> 1.  Continue to support the pipe and multiple pipe syntax.  Cells  
> that span
> more than 3 columns are very rare, and many of these may be done  
> with a
> title instead, or be broken into multiple tables that are floated  
> inline.

+1

> 2.  Use quotes for row span.

Or see what cow paths develop.

Best,

David