Re: Proposed table specification (long!)

[Simon Bull]

## Teardown Table Specification

1.  Teardown Tables
1.  The Simplest Table

2.  Basic Table Features
1.  The Header
a.  Basic Header
b.  Multi-Line Header
2.  The Title
3.  Rows
a.  Clean Rows
b.  Multi-Line Rows
c.  Ruled Rows
4.  Columns
a.  Clean Cols
b.  Ruled Columns
5.  Ruled Rows and Ruled Columns
6.  The Footer

3.  Advanced Table Features
1.  Cell Spans
a.  Rowspan
b.  Colspan
2.  Cell Alignment
a.  Vertical Alignment
b.  Horizontal Alignment
3.  Advanced Headers
4.  Empty Cells
5.  Nested Tables
6.  Multiple Bodies
7.  Vertical Table Header

4.  Putting it all Together
1.  A Complex Markeddown Table



## 1. Teardown Tables

A table is an arrangement of terms into rows and columns.


### 1.1. The Simplest Table

Here is a very simple Teardown table with three rows and three columns
(examples are delimited by PHP Markdown Extra fence blocks throughout):

~


  Elves  RivendellSindarin
  DwarvesErebor   Khuzdul
  HobbitsThe ShireWestron


~

It is the *visual alignment* of terms into rows and columns which makes the
whole recognisable as a table to the reader.

It is the two leading (and trailing) line breaks which signal the beginning
(and end) of a table to the parser, however.

Additionally, we can see that:
*   A line-break indicates a row-break,
*   Any 3 or more space symbols indicates a column-break.

That is the _very least_ you need to know in order to write Teardown tables.


## 2. Basic Table Features

The "very least" is not enough to satisfy all authoring needs.  For example,
empty table cells are not supported by Simplest Table (above).

Teardown specifies a number of additional features which, combined, aim to
address all but the most tricky cases.


### 2.1.  The Header

It is very often desirable to label columns of terms with a row of headings.

If included, this row of column headings is called the "Header".

The Header is separated from the table Body by a line of equals symbols
called the "Line".

The table Header is always above the Line, and the table Body is always
below the Line.


 2.1.a.  Basic Header

The Header is authored as per any other row in the table Body.  It is a
series of terms at the top of a like series of aligned columns.  3 or more
space symbols denote a column-break, just as they do in the Body of the
table.

E.g.,

~


  People Homeland Tongue

  Elves  RivendellSindarin
  DwarvesErebor   Khuzdul
  HobbitsThe ShireWestron


~


 2.1.b.  Multi-Line Header

Header text can occupy more than line in the Header.  E.g.,

~


  Name of Spoken
  People Homeland Tongue

  Elves  RivendellSindarin
  DwarvesErebor   Khuzdul
  HobbitsThe ShireWestron


~

Note the single line "Homeland" column header.  Empty cells and cell spans
are discussed in section 3 (Advanced Table Features, below).  But even
disregarding section 3, a parser can count the number of characters to
determine which column the text "Spoken" belongs to.


### 2.2. The Title

It is often desirable to label a table with a title.

If included, a Title is any text between two unbroken lines of minus symbols
which precede the table itself.  E.g.,

~



 THE PEOPLE OF MIDDLE-EARTH


  People Homeland Tongue

  Elves  RivendellSindarin
  DwarvesErebor   Khuzdul
  HobbitsThe ShireWestron


~


### 2.3. Rows

Rows of columns make up the Body of a table.

 2.3.a.  Clean Rows

Clean rows (so called because the markdown is uncluttered) are separated by
a line-break.  E.g.,

~


  People Homeland Tongue

  Elves  RivendellSindarin

  DwarvesErebor   Khuzdul

  HobbitsThe ShireWestron


~

Note that the more compact form used in example 1.1 (above) is ambiguous as
to whether there are three lines of text in a single row, or a single line
of text in each of three rows.  In this example, there is no such ambiguity.


 2.3.b. Multi-Line Rows

Multi-lined rows are also allowed;

~


  People Homeland Tongue

  Elves  Rivendell,   Quenya,
 Mirkwood,Sindarin,
 Lorien   Nandorin

  DwarvesErebor   Khuzdul

  HobbitsThe Shire,   Westron
 Breeland


~

It is clear now that the compact form used in example 1.1 (above) would
unambiguously be interpreted as three lines of text in a single row.

Re: Proposed table specification (long!)

[Simon Bull]

## 3. Advanced Table Features


### 3.1. Cell Spans

Rowspans and colspans appear relatively infrequently.  However, it is nice
to know that your markdown implementation supports these if/when the need
arises.


 3.1.a. Colspan

To make use of colspans the author must use Ruled Rows (as described above).

Thereafter it is a simple matter to merge two adjacent table cells by
omitting the explicit space denoted col-break between them.  E.g.,

~


|  People   | Homeland   | Tongue|
 
|  Elves| Rivendell, | Quenya,   |
|   | Mirkwood,  | Sindarin, |
|   | Lorien | Nandorin  |
 ---  ---
|  Dwarves  | THESE CELLS ARE MERGED |
 --- 
|  Hobbits  | The Shire, | Westron   |
|   | Breeland   |   |
 ---  ---


~

Note that the row-rule _below_ "THESE CELLS ARE MERGED" is continuous.
I.e., it does *not* contain a space.


 3.1.b.  Rowspan

To make use of rowspans the author must use Ruled Columns (as described
above).

Thereafter it is a simple matter to merge two adjacent table cells by
omitting the explicit space denoted row-break between them.  E.g.,

~


|  People   | Homeland   | Tongue|
 
|  Elves| Rivendell, | Quenya,   |
|   | Mirkwood,  | Sindarin, |
|   | Lorien | Nandorin  |
 ---  ---
|  Dwarves  | Erebor | THESE |
 ---   TWO CELLS |
|  Hobbits  | The Shire, | ARE   |
|   | Breeland   | MERGED|
 ---  ---


~

Note that the Column-Rule _after_ "THESE TWO CELLS ARE MERGED" is
continuous.  I.e., it does *not* contain a break.



### 3.2. Cell Alignment

The author has already provided the desired text alignment in the original
(mono spaced) markdown text.

It is therefore plausible for a parser to derive cell alignment by comparing
the amount of leading and trailing white space in each table cell of each
row and each column.

Given this there is no genuine need for the author to provide further parser
hints.  Moreover, there is a greater incentive to abstain from polluting the
markdown with parser metadata, as this degrades the readers' experience of
the document.


### 3.3. Advanced Headers

A table Header can include any of the row and column features of the table
Body, including multiple rows of text, rowspan and colspan.

The only notable difference is that a Row-Rule is _above_ the row it
describes in the Header, rather than _below_ it (as it would be in the table
Body).

~


 --- 
|  ROWSPAN  |   COLSPAN IN HEADER|
|IN | ---
|  HEADER   | Homeland   | Tongue|
 
|  Elves| Rivendell, | Quenya,   |
|   | Mirkwood,  | Sindarin, |
|   | Lorien | Nandorin  |
 ---  ---
|  Dwarves  | Erebor | Khuzdul   |
 ---  ---
|  Hobbits  | The Shire, | Westron   |
|   | Breeland   |   |
 ---  ---


~


### 3.4. Empty Cells

Empty cells are explicitly supported if the author chooses to use Ruled
Columns and Ruled Rows (see above).

Otherwise, it is left to the parser to decide if white space represents an
empty cell or not.  Whether or not the parser counts leading and trailing
white spaces around cell content to make this judgement if left to the
implementation.


### 3.5. Nested Tables

Nested tables are not explicitly supported.


### 3.6. Multiple Table Bodies

The (first) table Body begins immediatley after the Line separating the
Header for the table content, e.g., "===".

In fact, it is perfectly legal to insert one _or more_ Lines, so long as
each is followed by at least one row of genuine data.  E.g.,

~


 ---  ---
|  People   | Homeland   | Tongue|
 
|  Elves| Rivendell, | Quenya,   |
|   | Mirkwood,  | Sindarin, |
|   | Lorien | Nandorin  |
 ---  ---
|  Dwarves  | Erebor | Khuzdul   |
 ---  ---
|  Hobbits  | The Shire, | Westron   |
|   | Breeland   |   |
 
|  Men  | Andor, | Westron   |
|   | Gondor |   |
 ---  ---
|  Orcs | Angbad,| The Black |
|   | Mordor | Speak |
 ---  ---


~

Cell spanning is not permitted across Bodies.



### 3.7. Vertical Table Header

It is legal to orient the Header vert

Re: Proposed table specification (long!)

[Waylan Limberg]

On Tue, May 10, 2011 at 8:31 AM, Simon Bull  wrote:
> Gentlefolk,
>
> I have been thinking on Markdown's lack of "proper" table support for a long
> while now.  Here's where I have arrived...
>
>
> ## I Don't Like HTML Tables
>
> It is often argued that embedded HTML is the way to markdown rich tables.
>
> Unfortunately, this contradicts the higher markdown ideal that a raw
> markdown document (including tables!) should be good
>
> 1. Firstly for readers,
> 2. Secondly for authors,
> 3. Lastly for parsers which don't even rate a mention because markdown is
> for Humans.
>

In response to this I will quote the paragraph from the syntax rules
[1] which likely gave you this impression:

> Markdown is not a replacement for HTML, or even close to it. Its syntax is 
> very
> small, corresponding only to a very small subset of HTML tags. The idea is not
> to create a syntax that makes it easier to insert HTML tags. In my opinion, 
> HTML
> tags are already easy to insert. The idea for Markdown is to make it easy to 
> read,
> write, and edit prose. HTML is a publishing format; Markdown is a writing 
> format.
> Thus, Markdown’s formatting syntax only addresses issues that can be conveyed
> in plain text.

Note that is says "easy to read, write, and edit prose" -- "prose" not
tabular data. Taking this (along with the rest of that section of the
document, it is clear (to me at least) that there is no place for a
table syntax in markdown. Now, if you want to implement a third party
add-on, fine. And if that third party add-on becomes popular, then
maybe others will add it to there implementations as well. Maybe,
eventually, if a single format becomes popular enough, the community
at large will accept it. Until then, I'm not interested. If you want
it, go build it!

[1]: http://daringfireball.net/projects/markdown/syntax#html

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 10, 2011, at 5:31 AM, Simon Bull wrote:


Gentlefolk,

I have been thinking on Markdown's lack of "proper" table support  
for a long while now.  Here's where I have arrived...


.
.
.
*Please note* that I have _not_ implemented this specification.   
This is all just hot air produced by an author trying contribute  
something toward better table support for markdown.



I think this is a case where you'd do better writing
a table preprocessor that implements your table extension.
Yours is a fairly complex implementation, and there's not
a painless way for people to try it out.The existing
table implementation (the php markdown extra one) is kind
of klunky and horrible, but the code is there and authors
can actually see a working implementation before going and
implementing it themselves.   Yours, at least as of right
now, is just documentation and not very useful for getting
ones fingers into the pie.


-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Thanks for your replies gentlemen.  I'm not surprised by the lack of...
"enthusiasm".

I would like to add, in reply to Waylan's comment about "prose", that
markdown already includes syntax for lists, link, horizontal rules, images
and so on which are not "prose" either.  Surely markdown can only be a more
useful tool with table support than without it.

I agree with David's comment that the specification needs an implementation
before people will take it seriously.  I did, however, think it was a
reasonable notion to firstly propose a solution, then have it reviewed by a
meaningful authority (i.e., this list), and then think about implementing
it.

I will leave it to simmer a while before I go any further with it.

Thanks again,

Simon



On Tue, May 10, 2011 at 11:37 PM, David Parsons wrote:

>
> On May 10, 2011, at 5:31 AM, Simon Bull wrote:
>
>  Gentlefolk,
>>
>> I have been thinking on Markdown's lack of "proper" table support for a
>> long while now.  Here's where I have arrived...
>>
>
>.
>.
>
>.
>
>> *Please note* that I have _not_ implemented this specification.  This is
>> all just hot air produced by an author trying contribute something toward
>> better table support for markdown.
>>
>
>
>I think this is a case where you'd do better writing
> a table preprocessor that implements your table extension.
> Yours is a fairly complex implementation, and there's not
> a painless way for people to try it out.The existing
> table implementation (the php markdown extra one) is kind
> of klunky and horrible, but the code is there and authors
> can actually see a working implementation before going and
> implementing it themselves.   Yours, at least as of right
> now, is just documentation and not very useful for getting
> ones fingers into the pie.
>
>
> -david parsons
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Fletcher T. Penney]

Additions to the MMD table syntax (which is largely based on PHP
Markdown Extra) is probably one of the most common feature requests I
get.

My response is usually always the same - I'll update the syntax when I
see a proposal that is:

* easy/natural to write
* easy/natural to read
* easy to program a computer to parse
* uncluttered

I realize that beauty is in the eye of the beholder in these cases,
but I have yet to see a proposal that beats the current syntax in all
(or even most) of these criteria.  I would love to add additional
features to MMD tables (cells that span multiple rows, improved syntax
for wrapping long cell contents, etc) but not at the expense of
further complicating the syntax.


My $.02,

Fletcher


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Hi Fletcher,

Should I assume that you mean the proposed syntax falls short in one or more
of the four categories you identified?

If you care to elaborate on some of these short-comings I would be very
happy to alter my proposal in order to meet the needs of a wider audience.
That was in fact the purpose of proposing it at all.

Thanks for your comments,

Simon


On Wed, May 11, 2011 at 10:37 AM, Fletcher T. Penney <
fletc...@fletcherpenney.net> wrote:

> Additions to the MMD table syntax (which is largely based on PHP
> Markdown Extra) is probably one of the most common feature requests I
> get.
>
> My response is usually always the same - I'll update the syntax when I
> see a proposal that is:
>
> * easy/natural to write
> * easy/natural to read
> * easy to program a computer to parse
> * uncluttered
>
> I realize that beauty is in the eye of the beholder in these cases,
> but I have yet to see a proposal that beats the current syntax in all
> (or even most) of these criteria.  I would love to add additional
> features to MMD tables (cells that span multiple rows, improved syntax
> for wrapping long cell contents, etc) but not at the expense of
> further complicating the syntax.
>
>
> My $.02,
>
> Fletcher
>
>
> --
> Fletcher T. Penney
> fletc...@fletcherpenney.net
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Fletcher T. Penney]

Since you asked, here are my own personal thoughts - others most
likely disagree


The syntax seems a bit complicated - I didn't compare, but I suspect
the length of your explanation approaches or exceeds the entire
Markdown syntax guide.  I realize that you are trying to offer some
flexibility, but that can get tricky.

The other challenge is "editability" - with most of the complex table
formats out there, it would be very tedious to actually create and
subsequently modify a table by hand.  I will grant you that this as
much (or more) a problem with editors than the syntax.  And one could
create plugins for certain editors (e.g. TextMate) that could do the
formatting for you.  But this seems to be straying outside the bounds
of what makes Markdown so great. (Again --- just my opinion)

But I think the biggest issue is the monospace vs proportional font
problem.  This plagues every proposed table syntax out there (to my
knowledge) --- tables just aren't going to look right in both font
types in plain text files.  Proper alignment is a key feature of
tables, and it's frustrating when this is destroyed by changing the
font.

That said, the elastic tabstop idea proposed by Nick Gravgaard offers
a tantalizing solution to this problem.  In text editors that
supported this concept, it would be trivially easy to align columns of
text that worked for both monospace and proportional fonts.  Columns
would automatically realign when you changed the length of a given
cell.

In general, I believe there is a trade-off between simplicity and
functionality.  My preference is not to sacrifice (much) simplicity
for the sake of functionality --- I believe MMD's table syntax is
about as far down that curve as I am willing to go.  Others may be on
the other end of the spectrum.

Where true genius comes is being able to merge simplicity with
functionality (e.g. the iphone).  I'm not saying a great solution for
the Markdown/Table dilemma doesn't exist.  I just don't think I've
seen it yet.  But I agree with you that continuing to generate new
proposals is a good idea.

F-



On Tue, May 10, 2011 at 9:22 PM, Simon Bull  wrote:
> Hi Fletcher,
>
> Should I assume that you mean the proposed syntax falls short in one or more
> of the four categories you identified?
>
> If you care to elaborate on some of these short-comings I would be very
> happy to alter my proposal in order to meet the needs of a wider audience.
> That was in fact the purpose of proposing it at all.
>
> Thanks for your comments,
>
> Simon
>

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Thanks for your additional comments Fletcher.


If the proposed syntax overly complicated, I am very happy to simplify it.
The question is whether or not the following is really complicated?

~


---
 THE PEOPLE OF MIDDLE-EARTH
---

  PeopleHomelandTongue
===
  Elves Rivendell,  Quenya,
Mirkwood,   Sindarin,
Lorien  Nandorin

  Dwarves   Erebor  Khuzdul

  Hobbits   The Shire,  Westron
Breeland


~

Sure, if you want the rowspan and/or colspan features you will have to use
the ruled cols and/or ruled rows form.  But those are optional features that
many authors might use only rarely.  Likewise, a particular implementation
could choose to either support/not support those optional features.  But at
least there would be a potential upgrade path from the most basic table
support to the fullest table support.

The proposed specification is only verbose because I decided to illustrate
every feature individually with an explicit example.  If you prefer I could
give the entire proposal in one or two examples instead.

The issues around editors and mon-spacing are bigger than this proposal, so
I won't attempt to address those here.

Thanks again for your ever insightful comments Fletcher ,

Simon


On Wed, May 11, 2011 at 11:47 AM, Fletcher T. Penney <
fletc...@fletcherpenney.net> wrote:

> Since you asked, here are my own personal thoughts - others most
> likely disagree
>
>
> The syntax seems a bit complicated - I didn't compare, but I suspect
> the length of your explanation approaches or exceeds the entire
> Markdown syntax guide.  I realize that you are trying to offer some
> flexibility, but that can get tricky.
>
> The other challenge is "editability" - with most of the complex table
> formats out there, it would be very tedious to actually create and
> subsequently modify a table by hand.  I will grant you that this as
> much (or more) a problem with editors than the syntax.  And one could
> create plugins for certain editors (e.g. TextMate) that could do the
> formatting for you.  But this seems to be straying outside the bounds
> of what makes Markdown so great. (Again --- just my opinion)
>
> But I think the biggest issue is the monospace vs proportional font
> problem.  This plagues every proposed table syntax out there (to my
> knowledge) --- tables just aren't going to look right in both font
> types in plain text files.  Proper alignment is a key feature of
> tables, and it's frustrating when this is destroyed by changing the
> font.
>
> That said, the elastic tabstop idea proposed by Nick Gravgaard offers
> a tantalizing solution to this problem.  In text editors that
> supported this concept, it would be trivially easy to align columns of
> text that worked for both monospace and proportional fonts.  Columns
> would automatically realign when you changed the length of a given
> cell.
>
> In general, I believe there is a trade-off between simplicity and
> functionality.  My preference is not to sacrifice (much) simplicity
> for the sake of functionality --- I believe MMD's table syntax is
> about as far down that curve as I am willing to go.  Others may be on
> the other end of the spectrum.
>
> Where true genius comes is being able to merge simplicity with
> functionality (e.g. the iphone).  I'm not saying a great solution for
> the Markdown/Table dilemma doesn't exist.  I just don't think I've
> seen it yet.  But I agree with you that continuing to generate new
> proposals is a good idea.
>
> F-
>
>
>
> On Tue, May 10, 2011 at 9:22 PM, Simon Bull 
> wrote:
> > Hi Fletcher,
> >
> > Should I assume that you mean the proposed syntax falls short in one or
> more
> > of the four categories you identified?
> >
> > If you care to elaborate on some of these short-comings I would be very
> > happy to alter my proposal in order to meet the needs of a wider
> audience.
> > That was in fact the purpose of proposing it at all.
> >
> > Thanks for your comments,
> >
> > Simon
> >
>
> --
> Fletcher T. Penney
> fletc...@fletcherpenney.net
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 10, 2011, at 8:54 PM, Simon Bull wrote:


Thanks for your additional comments Fletcher.


If the proposed syntax overly complicated, I am very happy to  
simplify it.  The question is whether or not the following is really  
complicated?



  Implement what you have, and then you'll have an idea if it's too
complicated.   Working code is the best test of the complexity of a
design.


   -david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Thomas Humiston]

Notes from a writer who makes occasional light use of Markdown and is  
not involved in implementations at all (nor especially familiar with  
other -down table syntaxes):


I view my plain-text emails in a proportional font (Verdana). Simon's  
tables look ragged that way, but readable and not terribly unpleasant.


Such decoding of occasional monospace-intended bits is, in my view, a  
fairly conventional matter in email, and thus congruent with  
Markdown's inspiration. Perhaps the matter of mono vs. proportional is  
not such a bugbear after all, at least for small-to-medium tables (and  
for the rest, there's always HTML).


But wait -- Given 2.1.b's handling of empty cells, it seems the  
proposal still assumes some degree of monospace involvement.  
Similarly, 3.1.a speaks of omitting a space-denoted column break from  
"between" two columns, a break that is "between" in a sense (either  
visual or numeric) that's likely obvious in monospace only.


So in the proposal, colspans do depend on character counts, and thus  
on monospace writing tools (except in tables simple enough for manual  
counting). Well, I suppose most authors of Markdown texts use such  
tools anyway.


A confusing bit for me: Section 2.3.b leaves me thinking that the  
compact form is usable only for single-row bodies, and NOT for, say,  
"three rows and three columns" as indicated in Section 1.1. Also, I'd  
suggest instructing authors to use "blank lines" as Gruber does  
instead of "line breaks" (as the latter connotes carriage returns and/ 
or newline characters).


- TH


Simon Bull wrote:


~


   ---
THE PEOPLE OF MIDDLE-EARTH
   ---

 PeopleHomelandTongue
   ===
 Elves Rivendell,  Quenya,
   Mirkwood,   Sindarin,
   Lorien  Nandorin

 Dwarves   Erebor  Khuzdul

 Hobbits   The Shire,  Westron
   Breeland


~


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Hello Thomas,

In reply to your comments...

Yes, I have assumed mono-spaced (or equivalent) rendering throughout.

Comparing examples 1.1 and example 2.3.b, yes you are correct.  I need to
update the description given for 1.1 (the so called "compact form").  The
compact form (without blank lines or rules between rows) will always result
in a single table row with multiple lines per row.

However, it would be possible to also specify a "single line per row"
interpretation if that is a desired feature.

Your comment re: "line breaks" versus "blank lines" is also taken on board.

Thanks for your valuable comments,

Simon


On Wed, May 11, 2011 at 4:45 PM, Thomas Humiston wrote:

> Notes from a writer who makes occasional light use of Markdown and is not
> involved in implementations at all (nor especially familiar with other -down
> table syntaxes):
>
> I view my plain-text emails in a proportional font (Verdana). Simon's
> tables look ragged that way, but readable and not terribly unpleasant.
>
> Such decoding of occasional monospace-intended bits is, in my view, a
> fairly conventional matter in email, and thus congruent with Markdown's
> inspiration. Perhaps the matter of mono vs. proportional is not such a
> bugbear after all, at least for small-to-medium tables (and for the rest,
> there's always HTML).
>
> But wait -- Given 2.1.b's handling of empty cells, it seems the proposal
> still assumes some degree of monospace involvement. Similarly, 3.1.a speaks
> of omitting a space-denoted column break from "between" two columns, a break
> that is "between" in a sense (either visual or numeric) that's likely
> obvious in monospace only.
>
> So in the proposal, colspans do depend on character counts, and thus on
> monospace writing tools (except in tables simple enough for manual
> counting). Well, I suppose most authors of Markdown texts use such tools
> anyway.
>
> A confusing bit for me: Section 2.3.b leaves me thinking that the compact
> form is usable only for single-row bodies, and NOT for, say, "three rows and
> three columns" as indicated in Section 1.1. Also, I'd suggest instructing
> authors to use "blank lines" as Gruber does instead of "line breaks" (as the
> latter connotes carriage returns and/or newline characters).
>
> - TH
>
>
>
> Simon Bull wrote:
>
>  ~
>>
>>
>>   ---
>>THE PEOPLE OF MIDDLE-EARTH
>>   ---
>>
>> PeopleHomelandTongue
>>   ===
>> Elves Rivendell,  Quenya,
>>   Mirkwood,   Sindarin,
>>   Lorien  Nandorin
>>
>> Dwarves   Erebor  Khuzdul
>>
>> Hobbits   The Shire,  Westron
>>   Breeland
>>
>>
>> ~
>>
>>  ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Chambers]

Fletcher T. Penney  wrote:

   But I think the biggest issue is the monospace vs proportional
> font problem.  This plagues every proposed table syntax out there (to
> my knowledge) --- tables just aren't going to look right in both font types
> in plain text files.  Proper alignment is a key feature of tables, and it's
> frustrating when this is destroyed by changing the font.


The fact that columns in such tables are not aligned when a proportional
font is used is not pertinent, in my opinion. Even a *jagged* "Markdown"
table does a better job of representing data in a tabular fashion than
HTML's mess of s, s, and s.

David


On 11 May 2011 00:09, Simon Bull  wrote:

> Hello Thomas,
>
> In reply to your comments...
>
> Yes, I have assumed mono-spaced (or equivalent) rendering throughout.
>
> Comparing examples 1.1 and example 2.3.b, yes you are correct.  I need to
> update the description given for 1.1 (the so called "compact form").  The
> compact form (without blank lines or rules between rows) will always result
> in a single table row with multiple lines per row.
>
> However, it would be possible to also specify a "single line per row"
> interpretation if that is a desired feature.
>
> Your comment re: "line breaks" versus "blank lines" is also taken on board.
>
> Thanks for your valuable comments,
>
> Simon
>
>
>
> On Wed, May 11, 2011 at 4:45 PM, Thomas Humiston wrote:
>
>> Notes from a writer who makes occasional light use of Markdown and is not
>> involved in implementations at all (nor especially familiar with other -down
>> table syntaxes):
>>
>> I view my plain-text emails in a proportional font (Verdana). Simon's
>> tables look ragged that way, but readable and not terribly unpleasant.
>>
>> Such decoding of occasional monospace-intended bits is, in my view, a
>> fairly conventional matter in email, and thus congruent with Markdown's
>> inspiration. Perhaps the matter of mono vs. proportional is not such a
>> bugbear after all, at least for small-to-medium tables (and for the rest,
>> there's always HTML).
>>
>> But wait -- Given 2.1.b's handling of empty cells, it seems the proposal
>> still assumes some degree of monospace involvement. Similarly, 3.1.a speaks
>> of omitting a space-denoted column break from "between" two columns, a break
>> that is "between" in a sense (either visual or numeric) that's likely
>> obvious in monospace only.
>>
>> So in the proposal, colspans do depend on character counts, and thus on
>> monospace writing tools (except in tables simple enough for manual
>> counting). Well, I suppose most authors of Markdown texts use such tools
>> anyway.
>>
>> A confusing bit for me: Section 2.3.b leaves me thinking that the compact
>> form is usable only for single-row bodies, and NOT for, say, "three rows and
>> three columns" as indicated in Section 1.1. Also, I'd suggest instructing
>> authors to use "blank lines" as Gruber does instead of "line breaks" (as the
>> latter connotes carriage returns and/or newline characters).
>>
>> - TH
>>
>>
>>
>> Simon Bull wrote:
>>
>>  ~
>>>
>>>
>>>   ---
>>>THE PEOPLE OF MIDDLE-EARTH
>>>   ---
>>>
>>> PeopleHomelandTongue
>>>   ===
>>> Elves Rivendell,  Quenya,
>>>   Mirkwood,   Sindarin,
>>>   Lorien  Nandorin
>>>
>>> Dwarves   Erebor  Khuzdul
>>>
>>> Hobbits   The Shire,  Westron
>>>   Breeland
>>>
>>>
>>> ~
>>>
>>>  ___
>> Markdown-Discuss mailing list
>> Markdown-Discuss@six.pairlist.net
>> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>>
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Michel Fortin]

Le 2011-05-10 à 23:54, Simon Bull a écrit :

> If the proposed syntax overly complicated, I am very happy to simplify it.
> The question is whether or not the following is really complicated?
> 
> ~
> 
> 
>---
> THE PEOPLE OF MIDDLE-EARTH
>---
> 
>  PeopleHomelandTongue
>===
>  Elves Rivendell,  Quenya,
>Mirkwood,   Sindarin,
>Lorien  Nandorin
> 
>  Dwarves   Erebor  Khuzdul
> 
>  Hobbits   The Shire,  Westron
>Breeland
> 
> 
> ~

I agree with most of Fletcher's points. This is complicated. I made a parser 
that can parse something relatively similar to the above before settling on PHP 
Markdown Extra's current table syntax. I decided against it for a couple of 
reasons.

First, it relies on spacing too much. With most syntaxes in Markdown, you can 
be lazy and not indent everything perfectly. This table syntax relies entirely 
on perfect spacing, which goes contrary to this principle. It also only work 
with monospace fonts which can be a problem in some cases.

Second, editing its content is a real pain. Try to add a new elven tongue 
between "Quenya" and "Sindarin" and tell me how much time it takes. Now compare 
with editing the same table in HTML.

I'll concede that the table is more readable than in HTML, but I think the 
ratio between usefulness and implementation effort is rather weak.

And did I miss it or does it lacks one feature PHP Markdown Extra has: 
per-column left/right/center alignment?


-- 
Michel Fortin
michel.for...@michelf.com
http://michelf.com/



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Thanks for your comments Michel.

In reply to the points you raise:


Regarding complexity:
It is not clear to me whether folks are objecting to _parsing_ complexity or
*reading/writing* complexity.  Subjectively I don't think the example is
difficult to read; it couldn't be much simpler.  So I will assume that
people are concerned about parsing complexity.  On this I cannot comment
except to say that I believe reading/writing considerations should drive the
specification which should drive the implementation.  Implementation
considerations should not drive the formulation of the specification except
where some absolute technical limitation dictates otherwise.


Regarding spacing:
Firstly may I say that I do believe good spacing is good practice for
tables.
>From my original post...
>It is the _visual alignment_ of terms into rows and columns that enables a
reader to recognise a table.
>Without any recognisable alignment, a reader sees a jumbled "cloud" of
terms
"good" doesn't have to mean "perfect", however.

Secondly, as an author I take pride in producing beautiful documents.  If a
document looks a mess then the author looks careless, lazy and less
credible.  Additionally, from JG's introduction at Daring Fireball:
>The overriding design goal for Markdown’s formatting syntax is to make it
as readable as possible.
>The idea is that a Markdown-formatted document should be publishable as-is,
as plain text,

A markdown document should be *publishable* _as-is_.  Wobbly mis-aligned
tables do not make publishable documents in any profession as far as I know.


Regarding ease of editing :
The difficult with inserting text into a column is a general problem with
text editing tools and table formats in general.  It is not a specific
problem with the proposed table syntax.  Moreover, various text editors do
support a "block" or "column" select feature which enables the author to
select, copy, cut and paste columns (or blocks) of text.  This editor
feature facilitates exactly the kind of operation you mentioned.

That aside, the proposed table syntax supports a more trivial (lazy) method
of inserting text into the middle of a column in a few seconds, like this:

Before:

  People Homeland Tongue

  Elves  Rivendell,   Quenya,
 Mirkwood,Sindarin,
 Lorien   Nandorin

  DwarvesErebor   Khuzdul

  HobbitsThe Shire,   Westron
 Breeland


After:

  People Homeland Tongue

  Elves  Rivendell,   Quenya,
  Telerin,   <--- inserted text
 Mirkwood,Sindarin,
 Lorien   Nandorin

  DwarvesErebor   Khuzdul

  HobbitsThe Shire,   Westron
 Breeland



Regarding cell alignment :
In my original post I wrote this
> The author has already provided the desired text alignment in the original

>(mono spaced) markdown text.
>
>It is therefore plausible for a parser to derive cell alignment by
comparing
> the amount of leading and trailing white space in each table cell of each
row
> and each column.

I am the first to concede that this would require near-perfect spacing in
the document, and would be very hard to implement.  It is therefore unlikely
that anyone would bother to implement it.

However, there's no reason not to include MMD-style cell alignment
meta-characters in the specification as a more practical short-cut if that
is what people want.


Thanks again for your comments Michel -- I hope I was able to communicate my
answers effectively and politely.

Simon


On Wed, May 11, 2011 at 9:00 PM, Michel Fortin wrote:

> Le 2011-05-10 à 23:54, Simon Bull a écrit :
>
> > If the proposed syntax overly complicated, I am very happy to simplify
> it.
> > The question is whether or not the following is really complicated?
> >
> > ~
> >
> >
> >---
> > THE PEOPLE OF MIDDLE-EARTH
> >---
> >
> >  PeopleHomelandTongue
> >===
> >  Elves Rivendell,  Quenya,
> >Mirkwood,   Sindarin,
> >Lorien  Nandorin
> >
> >  Dwarves   Erebor  Khuzdul
> >
> >  Hobbits   The Shire,  Westron
> >Breeland
> >
> >
> > ~
>
> I agree with most of Fletcher's points. This is complicated. I made a
> parser that can parse something relatively similar to the above before
> settling on PHP Markdown Extra's current table syntax. I decided against it
> for a couple of reasons.
>
> First, it relies on spacing too much. With most syntaxes in Markdown, you
> can be lazy and not indent everything perfectly. This table syntax relies
> entirely on perfect spacing, which goes contrary to this principle. It also
> only work with monospace fonts which can be a problem in some cases.
>
> S

Re: Proposed table specification (long!)

[Duke Normandin]

On Wed, 11 May 2011, Simon Bull wrote:

> Thanks for your comments Michel.
>
> In reply to the points you raise:
>
>
> Regarding complexity:
> It is not clear to me whether folks are objecting to _parsing_ complexity or
> *reading/writing* complexity.  Subjectively I don't think the example is
> difficult to read; it couldn't be much simpler.  So I will assume that
> people are concerned about parsing complexity.  On this I cannot comment
> except to say that I believe reading/writing considerations should drive the
> specification which should drive the implementation.  Implementation
> considerations should not drive the formulation of the specification except
> where some absolute technical limitation dictates otherwise.
>
>
> Regarding spacing:
> Firstly may I say that I do believe good spacing is good practice for
> tables.
> >From my original post...
> >It is the _visual alignment_ of terms into rows and columns that enables a
> reader to recognise a table.
> >Without any recognisable alignment, a reader sees a jumbled "cloud" of
> terms
> "good" doesn't have to mean "perfect", however.
>
> Secondly, as an author I take pride in producing beautiful documents.  If a
> document looks a mess then the author looks careless, lazy and less
> credible.  Additionally, from JG's introduction at Daring Fireball:
> >The overriding design goal for Markdown’s formatting syntax is to make it
> as readable as possible.
> >The idea is that a Markdown-formatted document should be publishable as-is,
> as plain text,
>
> A markdown document should be *publishable* _as-is_.  Wobbly mis-aligned
> tables do not make publishable documents in any profession as far as I know.
>
>
> Regarding ease of editing :
> The difficult with inserting text into a column is a general problem with
> text editing tools and table formats in general.  It is not a specific
> problem with the proposed table syntax.  Moreover, various text editors do
> support a "block" or "column" select feature which enables the author to
> select, copy, cut and paste columns (or blocks) of text.  This editor
> feature facilitates exactly the kind of operation you mentioned.
>
> That aside, the proposed table syntax supports a more trivial (lazy) method
> of inserting text into the middle of a column in a few seconds, like this:
>
> Before:
>
>   People Homeland Tongue
> 
>   Elves  Rivendell,   Quenya,
>  Mirkwood,Sindarin,
>  Lorien   Nandorin
>
>   DwarvesErebor   Khuzdul
>
>   HobbitsThe Shire,   Westron
>  Breeland
>
>
> After:
>
>   People Homeland Tongue
> 
>   Elves  Rivendell,   Quenya,
>   Telerin,   <--- inserted text
>  Mirkwood,Sindarin,
>  Lorien   Nandorin
>
>   DwarvesErebor   Khuzdul
>
>   HobbitsThe Shire,   Westron
>  Breeland
>
>
>
> Regarding cell alignment :
> In my original post I wrote this
> > The author has already provided the desired text alignment in the original
>
> >(mono spaced) markdown text.
> >
> >It is therefore plausible for a parser to derive cell alignment by
> comparing
> > the amount of leading and trailing white space in each table cell of each
> row
> > and each column.
>
> I am the first to concede that this would require near-perfect spacing in
> the document, and would be very hard to implement.  It is therefore unlikely
> that anyone would bother to implement it.
>
> However, there's no reason not to include MMD-style cell alignment
> meta-characters in the specification as a more practical short-cut if that
> is what people want.
>
>
> Thanks again for your comments Michel -- I hope I was able to communicate my
> answers effectively and politely.


I want to go on record as a strong supporter of your efforts. Your
willingness to consult your peers with this brain-storming effort does
you credit! However, IMHO, at the end of the day, you must follow your
intuition and good sense after taking all informed and uninformed
opinions into consideration. I like your proposal! It will be
interesting to use your proposal in due course.

-- 
Duke Normandin
Turner Valley, Alberta, Canada___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Thanks for your support Duke,

It's good to get some positive feedback mixed in with the constructive
criticism.

I will take it all on board, as you recommend.

Simon

On Thu, May 12, 2011 at 12:02 AM, Duke Normandin  wrote:

> On Wed, 11 May 2011, Simon Bull wrote:
>
> > Thanks for your comments Michel.
> >
> > In reply to the points you raise:
> >
> >
> > Regarding complexity:
> > It is not clear to me whether folks are objecting to _parsing_ complexity
> or
> > *reading/writing* complexity.  Subjectively I don't think the example is
> > difficult to read; it couldn't be much simpler.  So I will assume that
> > people are concerned about parsing complexity.  On this I cannot comment
> > except to say that I believe reading/writing considerations should drive
> the
> > specification which should drive the implementation.  Implementation
> > considerations should not drive the formulation of the specification
> except
> > where some absolute technical limitation dictates otherwise.
> >
> >
> > Regarding spacing:
> > Firstly may I say that I do believe good spacing is good practice for
> > tables.
> > >From my original post...
> > >It is the _visual alignment_ of terms into rows and columns that enables
> a
> > reader to recognise a table.
> > >Without any recognisable alignment, a reader sees a jumbled "cloud" of
> > terms
> > "good" doesn't have to mean "perfect", however.
> >
> > Secondly, as an author I take pride in producing beautiful documents.  If
> a
> > document looks a mess then the author looks careless, lazy and less
> > credible.  Additionally, from JG's introduction at Daring Fireball:
> > >The overriding design goal for Markdown’s formatting syntax is to make
> it
> > as readable as possible.
> > >The idea is that a Markdown-formatted document should be publishable
> as-is,
> > as plain text,
> >
> > A markdown document should be *publishable* _as-is_.  Wobbly mis-aligned
> > tables do not make publishable documents in any profession as far as I
> know.
> >
> >
> > Regarding ease of editing :
> > The difficult with inserting text into a column is a general problem with
> > text editing tools and table formats in general.  It is not a specific
> > problem with the proposed table syntax.  Moreover, various text editors
> do
> > support a "block" or "column" select feature which enables the author to
> > select, copy, cut and paste columns (or blocks) of text.  This editor
> > feature facilitates exactly the kind of operation you mentioned.
> >
> > That aside, the proposed table syntax supports a more trivial (lazy)
> method
> > of inserting text into the middle of a column in a few seconds, like
> this:
> >
> > Before:
> >
> >   People Homeland Tongue
> > 
> >   Elves  Rivendell,   Quenya,
> >  Mirkwood,Sindarin,
> >  Lorien   Nandorin
> >
> >   DwarvesErebor   Khuzdul
> >
> >   HobbitsThe Shire,   Westron
> >  Breeland
> >
> >
> > After:
> >
> >   People Homeland Tongue
> > 
> >   Elves  Rivendell,   Quenya,
> >   Telerin,   <--- inserted text
> >  Mirkwood,Sindarin,
> >  Lorien   Nandorin
> >
> >   DwarvesErebor   Khuzdul
> >
> >   HobbitsThe Shire,   Westron
> >  Breeland
> >
> >
> >
> > Regarding cell alignment :
> > In my original post I wrote this
> > > The author has already provided the desired text alignment in the
> original
> >
> > >(mono spaced) markdown text.
> > >
> > >It is therefore plausible for a parser to derive cell alignment by
> > comparing
> > > the amount of leading and trailing white space in each table cell of
> each
> > row
> > > and each column.
> >
> > I am the first to concede that this would require near-perfect spacing in
> > the document, and would be very hard to implement.  It is therefore
> unlikely
> > that anyone would bother to implement it.
> >
> > However, there's no reason not to include MMD-style cell alignment
> > meta-characters in the specification as a more practical short-cut if
> that
> > is what people want.
> >
> >
> > Thanks again for your comments Michel -- I hope I was able to communicate
> my
> > answers effectively and politely.
>
>
> I want to go on record as a strong supporter of your efforts. Your
> willingness to consult your peers with this brain-storming effort does
> you credit! However, IMHO, at the end of the day, you must follow your
> intuition and good sense after taking all informed and uninformed
> opinions into consideration. I like your proposal! It will be
> interesting to use your proposal in due course.
>
> --
> Duke Normandin
> Turner Valley, Alberta, Canada
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdow

Re: Proposed table specification (long!)

[Michel Fortin]

Le 2011-05-11 à 9:41, Simon Bull a écrit :

> Thanks for your comments Michel.

You're welcome.

> In reply to the points you raise:
> 
> 
> Regarding complexity:
> It is not clear to me whether folks are objecting to _parsing_ complexity or
> *reading/writing* complexity. Subjectively I don't think the example is
> difficult to read; it couldn't be much simpler.  So I will assume that
> people are concerned about parsing complexity.

It's pretty easy to read, no complexity problem there. I think the complexity 
lies in parsing, writing/editing, and explaining/understanding the 
possibilities.

> Implementation considerations should not drive the formulation of the 
> specification except
> where some absolute technical limitation dictates otherwise.

True, up to a point. It isn't worth investing tons of your time for a feature 
that'll benefit very few people (unless maybe yourself are one of those people, 
of course).

> A markdown document should be *publishable* _as-is_.  Wobbly mis-aligned
> tables do not make publishable documents in any profession as far as I know.

Well, the introduction says that indeed. Except that the role of Markdown is 
not to *enforce* this, but rather to *enable* it. And I'll say it's a success: 
most Markdown documents are indeed publishable as-is. In some circumstances 
however, the author has to make some efforts or find some tool to keep things 
pretty (multi-paragraph list items and blockquotes comes to mind). If you don't 
intend to publish the Markdown version, there is not much point to this effort 
and, thankfully, you can just skip it.

> Regarding ease of editing :
> The difficult with inserting text into a column is a general problem with
> text editing tools and table formats in general.  It is not a specific
> problem with the proposed table syntax.

My point about editing is that it's much easier to edit the HTML table than 
your table syntax because there is no grid to maintain.

> Regarding cell alignment :
> In my original post I wrote this
>> The author has already provided the desired text alignment in the original
>> (mono spaced) markdown text.
>> 
>> It is therefore plausible for a parser to derive cell alignment by comparing
>> the amount of leading and trailing white space in each table cell of each row
>> and each column.
> 
> I am the first to concede that this would require near-perfect spacing in
> the document, and would be very hard to implement.  It is therefore unlikely
> that anyone would bother to implement it.

Alignment deduction would likely be error prone too.

> However, there's no reason not to include MMD-style cell alignment
> meta-characters in the specification as a more practical short-cut if that
> is what people want.

Indeed.

> Thanks again for your comments Michel -- I hope I was able to communicate my
> answers effectively and politely.

It's an interesting discussion.

-- 
Michel Fortin
michel.for...@michelf.com
http://michelf.com/



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Dr. Drang]

I'm late to the party, but I do use tables in Markdown quite often, so…

Apart from the complexity of implementation, Fletcher's point about
monospaced and proportional fonts is the main objection to the
proposed syntax. I always use monospaced fonts, but not everyone does,
and Markdown is meant to accommodate everyone.

Michel's point about editing tables is also spot-on and ties into the
monospaced/proportional problem. Frankly, getting the proper alignment
when writing a table for the first time, even when using a monospaced
font, is a pain in the ass. Maintaining alignment when editing is even
harder—your example of adding a full line to one of the columns covers
only the simplest case.

The great thing about Michel's table syntax is that it allows you to
avoid these annoyances. You can align the columns if you want, but
you're not forced to. I happen to prefer aligned columns, which is why
I wrote this little script,

http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/

to do the alignment for me. But that's done outside of Markdown
itself; it's just a way of satisfying my anal retentiveness, not a
prescription for others.

Also, I'd like to address your use of rules within the table. Markdown
generates straight HTML—styles are left to the user's CSS. By adding
features that put borders in the table, you're inserting styles into
Markdown itself, which I think is a mistake.

Let me end by saying that I've always thought John was wrong not to
include a provision for tables in Markdown, and Michel's syntax
probably can be improved, so I welcome this discussion. But if tables
are to be included they should be simple, in keeping with Markdown's
overall approach. Markdown is not intended to handle every situation,
just the most common ones. The table formatting you've presented is
far more complex than the formatting Markdown does in other areas and,
I would argue, is beyond what Markdown should do.

Regards,
Dr. Drang
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Thanks for your well considered comments Dr.Drang,

I will take them on board along with all the others.

Simon

On Fri, May 13, 2011 at 2:33 AM, Dr. Drang  wrote:

> I'm late to the party, but I do use tables in Markdown quite often, so…
>
> Apart from the complexity of implementation, Fletcher's point about
> monospaced and proportional fonts is the main objection to the
> proposed syntax. I always use monospaced fonts, but not everyone does,
> and Markdown is meant to accommodate everyone.
>
> Michel's point about editing tables is also spot-on and ties into the
> monospaced/proportional problem. Frankly, getting the proper alignment
> when writing a table for the first time, even when using a monospaced
> font, is a pain in the ass. Maintaining alignment when editing is even
> harder—your example of adding a full line to one of the columns covers
> only the simplest case.
>
> The great thing about Michel's table syntax is that it allows you to
> avoid these annoyances. You can align the columns if you want, but
> you're not forced to. I happen to prefer aligned columns, which is why
> I wrote this little script,
>
> http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/
>
> to do the alignment for me. But that's done outside of Markdown
> itself; it's just a way of satisfying my anal retentiveness, not a
> prescription for others.
>
> Also, I'd like to address your use of rules within the table. Markdown
> generates straight HTML—styles are left to the user's CSS. By adding
> features that put borders in the table, you're inserting styles into
> Markdown itself, which I think is a mistake.
>
> Let me end by saying that I've always thought John was wrong not to
> include a provision for tables in Markdown, and Michel's syntax
> probably can be improved, so I welcome this discussion. But if tables
> are to be included they should be simple, in keeping with Markdown's
> overall approach. Markdown is not intended to handle every situation,
> just the most common ones. The table formatting you've presented is
> far more complex than the formatting Markdown does in other areas and,
> I would argue, is beyond what Markdown should do.
>
> Regards,
> Dr. Drang
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Michel and Dr.Dang both commented that it is easier to author/edit tables as
HTML than as aligned text.

I am not sure I personally agree with this, but assuming that it is true for
some significant part of the authorship, then I would like to add:

In my original post I stated my belief that the needs of the _reader_ come
before the needs of the _writer_.  I don't agree that the needs of one
author outweigh the needs of five hundred, ten, or even just two readers.
The writer may well be inconvenienced once by having to align text into a
table, but the *readers* are in inconvenienced n many times by having to
read tables of HTML.

Also, I believe that using the tab key to "tab" to the next column, or use
of scripts similar to Dr.Dang's[1] to align selected text at the touch of a
hot key should alleviate much of the authoring concern.

Finally, adding support for a richer table syntax would in no way replace
the existing support for HTML -- existing markdown documents containing
tables as HTML (and other HTML) would of course continue to be valid.
Therefore, HTML enthusiasts _could_ continue to author tables in HTML if
they really could not tolerate aligning text into tables by other means.

[1]:
http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/


Simon

On Thu, May 12, 2011 at 9:30 AM, Michel Fortin wrote:

> Le 2011-05-11 à 9:41, Simon Bull a écrit :
>
> > Thanks for your comments Michel.
>
> You're welcome.
>
> > In reply to the points you raise:
> >
> >
> > Regarding complexity:
> > It is not clear to me whether folks are objecting to _parsing_ complexity
> or
> > *reading/writing* complexity. Subjectively I don't think the example is
> > difficult to read; it couldn't be much simpler.  So I will assume that
> > people are concerned about parsing complexity.
>
> It's pretty easy to read, no complexity problem there. I think the
> complexity lies in parsing, writing/editing, and explaining/understanding
> the possibilities.
>
> > Implementation considerations should not drive the formulation of the
> specification except
> > where some absolute technical limitation dictates otherwise.
>
> True, up to a point. It isn't worth investing tons of your time for a
> feature that'll benefit very few people (unless maybe yourself are one of
> those people, of course).
>
> > A markdown document should be *publishable* _as-is_.  Wobbly mis-aligned
> > tables do not make publishable documents in any profession as far as I
> know.
>
> Well, the introduction says that indeed. Except that the role of Markdown
> is not to *enforce* this, but rather to *enable* it. And I'll say it's a
> success: most Markdown documents are indeed publishable as-is. In some
> circumstances however, the author has to make some efforts or find some tool
> to keep things pretty (multi-paragraph list items and blockquotes comes to
> mind). If you don't intend to publish the Markdown version, there is not
> much point to this effort and, thankfully, you can just skip it.
>
> > Regarding ease of editing :
> > The difficult with inserting text into a column is a general problem with
> > text editing tools and table formats in general.  It is not a specific
> > problem with the proposed table syntax.
>
> My point about editing is that it's much easier to edit the HTML table than
> your table syntax because there is no grid to maintain.
>
> > Regarding cell alignment :
> > In my original post I wrote this
> >> The author has already provided the desired text alignment in the
> original
> >> (mono spaced) markdown text.
> >>
> >> It is therefore plausible for a parser to derive cell alignment by
> comparing
> >> the amount of leading and trailing white space in each table cell of
> each row
> >> and each column.
> >
> > I am the first to concede that this would require near-perfect spacing in
> > the document, and would be very hard to implement.  It is therefore
> unlikely
> > that anyone would bother to implement it.
>
> Alignment deduction would likely be error prone too.
>
> > However, there's no reason not to include MMD-style cell alignment
> > meta-characters in the specification as a more practical short-cut if
> that
> > is what people want.
>
> Indeed.
>
> > Thanks again for your comments Michel -- I hope I was able to communicate
> my
> > answers effectively and politely.
>
> It's an interesting discussion.
>
> --
> Michel Fortin
> michel.for...@michelf.com
> http://michelf.com/
>
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 14, 2011, at 6:08 PM, Simon Bull wrote:

Michel and Dr.Dang both commented that it is easier to author/edit  
tables as HTML than as aligned text.


I am not sure I personally agree with this, but assuming that it is  
true for some significant part of the authorship, then I would like  
to add:


In my original post I stated my belief that the needs of the  
_reader_ come before the needs of the _writer_.  I don't agree that  
the needs of one author outweigh the needs of five hundred, ten, or  
even just two readers.  The writer may well be inconvenienced once  
by having to align text into a table, but the *readers* are in  
inconvenienced n many times by having to read tables of HTML.


   I presume that the readers will be reading the
entire document in html, via a viewer that renders
html into a more pleasing format.


   -david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Simon Bull]

Hi David,

Yes, as the published form of a markdown document, the HTML representation
of the document would presumably have a wide readership.

However, what if you want to include a markdown document, or even just a
fragment of markdown, in an email?   It might be forwarded to many readers
without ever being published as HTML.  What if you want to write markdown
for the purpose of a discussion group like this one?  It might be read by
hundreds of readers without ever being published as HTML.

Additionally, if you would like to see markdown as a supported input format
for tools such as wikis, forums, blogs, issue management systems, and so on
(in fact, any tool where the source document itself can be retrieved,
reviewed, and updated/edited inline) then your source document will possibly
be read and reread by many users over the life time of the document.

Perhaps these scenarios are worth considering too?

Simon

On Sun, May 15, 2011 at 2:01 PM, David Parsons wrote:

>
> On May 14, 2011, at 6:08 PM, Simon Bull wrote:
>
>  Michel and Dr.Dang both commented that it is easier to author/edit tables
>> as HTML than as aligned text.
>>
>> I am not sure I personally agree with this, but assuming that it is true
>> for some significant part of the authorship, then I would like to add:
>>
>> In my original post I stated my belief that the needs of the _reader_ come
>> before the needs of the _writer_.  I don't agree that the needs of one
>> author outweigh the needs of five hundred, ten, or even just two readers.
>>  The writer may well be inconvenienced once by having to align text into a
>> table, but the *readers* are in inconvenienced n many times by having to
>> read tables of HTML.
>>
>
>   I presume that the readers will be reading the
> entire document in html, via a viewer that renders
> html into a more pleasing format.
>
>
>   -david parsons
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On Sun, May 15, 2011 at 2:01 PM, I wrote:

  I presume that the readers will be reading the
entire document in html, via a viewer that renders
html into a more pleasing format.


On May 14, 2011, at 10:43 PM, Simon Bull wrote:


However, what if you want to include a markdown document, or even  
just a fragment of markdown, in an email?   It might be forwarded to  
many readers without ever being published as HTML.  What if you want  
to write markdown for the purpose of a discussion group like this  
one?  It might be read by hundreds of readers without ever being  
published as HTML.


Additionally, if you would like to see markdown as a supported input  
format for tools such as wikis, forums, blogs, issue management  
systems, and so on (in fact, any tool where the source document  
itself can be retrieved, reviewed, and updated/edited inline) then  
your source document will possibly be read and reread by many users  
over the life time of the document.


Perhaps these scenarios are worth considering too?


I believe you are grasping at straws here.Now, there's  
certainly nothing horribly wrong with your proposed implementation,  
but I do wish to restate that you would be much better off writing  
some code that implements your
proposal.   It doesn't even have to do a full markdownification of the  
output; a skeleton that takes as input a
document and translates your table blocks into html would be  
sufficient (and there are some markdown implementations
that support a "please markdownify me!" flag for html block elements;   
if you add those flags to your generated

html, you will have a program that can be pipelined like:

simontable < document.text | markdown > document.html

Don't convince us with words.  Convince us with code.

-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

simon-

i'm not sure persistence will do you much good.
nobody seems to have a desire to work together.
which is likely why there are 39 implementations.

an appeal on behalf of readers seems misguided,
since very few people are reading markdown text.

but a more potent case can be made for _re-use_.
the more easily content can be remixed, the better.

for my contender in the light-markup derby --
zen markup language (zml) -- to facilitate re-use,
my goal is that users can "round-trip" the text...

so if they copy the text out of the .pdf and use it 
to create _another_ .pdf, the two will be identical.

likewise, if they copy the text from a web-browser,
it will match the .zml file which created that .html.

or copy the text out of one version (.html or .pdf)
and use it to create the other version, just like that.

i am coming very close in both cases.   it'll certainly
be the case that some global changes will always be
required to restore the original .zml, but if i get it
down to just a few, that will be an accomplishment.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 15, 2011, at 10:17 AM, bowerb...@aol.com wrote:


simon-

i'm not sure persistence will do you much good.
nobody seems to have a desire to work together.
which is likely why there are 39 implementations.


Eh?

I can't speak for 37 of the 39 implementations, but I know that
in my case I *do* desire to work with the reference implementation;
the detail that I'm doing it in G-d's own programming language(tm)
was an artifact of not wanting to carry around Perl (Or python, or
any of the other interpreted web scripting languages) just to have
a reasonable markup language available to maintain my web pages.

The existance of the markdown discussion list is pretty good evidence
that there's a desire to work together.


-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Seumas Mac Uilleachan]

On 15/05/11 01:17 PM, bowerb...@aol.com wrote:

simon-

i'm not sure persistence will do you much good.
nobody seems to have a desire to work together.
which is likely why there are 39 implementations.

Isn't the existence of 39 implementations due to each implementer having 
their own favourite programming/scripting lamguage? And don't most (if 
not all) strive to follow the "canonical" Gruber perl markdown 
implementation? The inability to "work together" as you put it is due 
more th the percieved apathy of the originators of markdown in the last 
few years and the lack of an appointed/accepted successor.

an appeal on behalf of readers seems misguided,
since very few people are reading markdown text.

In my case I use markdown for a personal info management system and I 
read the text as often as the rendered html. But then it is my own text 
and I already know how I intended it to be interpreted.

but a more potent case can be made for _re-use_.
the more easily content can be remixed, the better.

for my contender in the light-markup derby --
zen markup language (zml) -- to facilitate re-use,
my goal is that users can "round-trip" the text...

so if they copy the text out of the .pdf and use it
to create _another_ .pdf, the two will be identical.

likewise, if they copy the text from a web-browser,
it will match the .zml file which created that .html.

or copy the text out of one version (.html or .pdf)
and use it to create the other version, just like that.

i am coming very close in both cases.  it'll certainly
be the case that some global changes will always be
required to restore the original .zml, but if i get it
down to just a few, that will be an accomplishment.

-bowerbird


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

i sent this a week ago.   (exactly 168 hours ago.)
but it never posted...   let's see if it posts now...

i was just gonna let it go, but i liked the phrase
"gruber is godot", so i decided to send it again...

gruber isn't going to take charge, folks.   really.

so if you want to move markdown forward, _you_
will have to act, collaboratively, which means you
must come together and become a collaborative...

but i sense you would all rather be the big fish
in your own small bowl.   which is fine with me...

-bowerbird

===
===
===

waylan said:
>there is no place for a table syntax in markdown.

well, gee, i guess that settles it...  :+)


>I'm not interested. If you want it, go build it! 

i wasn't under the impression that simon bull was
asking you to do the work.   but maybe i'm wrong...

***

david said:
>I think this is a case where you'd do 
>better writing   a table preprocessor 
>that implements your table extension.   
>Yours is a fairly complex implementation

i don't see anything "complex" in simon's formulation...
i'd guess i could probably program it in a couple hours.
and most of that would be fighting obtuse .html specs...

at the same time, however, i don't see anything in his
formulation that hasn't already been suggested before.

so i'm not sure why it hasn't been done.   by everyone.

why the foot-dragging?

are you all still waiting for gruber?
i've got news for you:   gruber is godot.
he ain't coming.   you might as well move on.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 17, 2011, at 1:46 PM, bowerb...@aol.com wrote:


david said:
>   I think this is a case where you'd do
>   better writing  a table preprocessor
>   that implements your table extension.
>   Yours is a fairly complex implementation

i don't see anything "complex" in simon's formulation...
i'd guess i could probably program it in a couple hours.
and most of that would be fighting obtuse .html specs...


Well, then why don't you do it?   It looks like
Simon would welcome your assistance, and if you could
write him an implementation of his table design then
he could get down to the interesting part of testing
it and making sure it works to his satisfaction.

-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

here's another one i thought twice about posting, but
what the heck...

***

ok, first of all, when i referred to 39 implementations,
i wasn't being critical.   how could i criticize any of you
for being off writing your own version of markdown
when i'm off writing my own version of light-markup?

my work _does_ predate that of gruber and swartz, but
i've still continued to do it, because i think my method
is _superior_ for the task at which my method is aimed;
thus i am not willing to concede the race to markdown.

so far be it from me to stab any of you for continuing
to pursue your own entry because you believe it to be
superior to the other contenders.   believe in yourself!

at the same time, though, it's a bit disingenuous to say
that the only differences are your choice of languages.

very few of you agree on edge-cases, and none of you
have explored the entire arena.   that's the reality here.

and that is not a dig, either.   the edge-cases are hard,
and if you try to chart the whole arena, you will likely
lose the simplicity that is one of markdown's big assets.
anyone tempted to move in that direction should look at
asciidoc.   it's very admirable in a way, but it's not simple.
who needs to reinvent .html markup without the brackets?

so, believe me, i understand the conundrum very well...

but still remaining at the same time, let us ask simon if
he thinks there is any desire to find a compromise here.

when it comes to tables, you put people in a catch-22...
it has to be something that can work with existing tools,
and it has to be something that can work with fonts that
are proportional and nonproportional.   surely you are all
smart enough to know that the clauses are contradictory.
the only reason to put people in a double-bind is if you
actively want to stall 'em out, in a passive way.   that's it.

edge-cases are not as clear of a catch-22, but even there,
you all have historic content you prefer not to "break" by
changing your implementation, so you are at an impasse.

but hey, if it makes you feel better, i would be happy to add
that all of this is "only in my own humble opinion", and that
"maybe i'm just not smart enough to see your solution", and
whatever other evasive language i would need to say so as to
protect you from feeling challenged or threatened, because
that's really _not_ my intention.   i have my own fish to fry...

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Michel Fortin]

Le 2011-05-17 à 17:24, bowerb...@aol.com a écrit :

> when it comes to tables, you put people in a catch-22...
> it has to be something that can work with existing tools,
> and it has to be something that can work with fonts that
> are proportional and nonproportional.   surely you are all
> smart enough to know that the clauses are contradictory.
> the only reason to put people in a double-bind is if you
> actively want to stall 'em out, in a passive way.   that's it.
> 
> edge-cases are not as clear of a catch-22, but even there,
> you all have historic content you prefer not to "break" by
> changing your implementation, so you are at an impasse.
> 
> but hey, if it makes you feel better, i would be happy to add
> that all of this is "only in my own humble opinion", and that
> "maybe i'm just not smart enough to see your solution", and
> whatever other evasive language i would need to say so as to
> protect you from feeling challenged or threatened, because
> that's really _not_ my intention.   i have my own fish to fry...

What we really need is an effort in the style of HTML5's HTML parsing algorithm 
which provides an unambiguous definition of how things should be parsed. Heck, 
I started one a while ago for Markdown Extra, first by creating a tool to be 
able to evaluate what each implementation do when encountering an edge case 
(Babelmark, which is now hosted at ), then by 
starting writing such a specification (see 
). Then I stopped because I realized 
it'd be too long and that I had many more interesting projects I could do in 
that free time.

HTML5 had some companies to back its development, Markdown doesn't. And it's 
not like any of us is making money selling our implementation of Markdown (or 
at least I don't), so I'm not sure how it'll happen.

Still, thanks for your analysis. It's refreshing to have an outsider's opinion 
one time in a while.

-- 
Michel Fortin
michel.for...@michelf.com
http://michelf.com/



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Dr. Drang]

On Tue, May 17, 2011 at 4:24 PM,   wrote:
>
> but hey, if it makes you feel better, i would be happy to add
> that all of this is "only in my own humble opinion", and that
> "maybe i'm just not smart enough to see your solution", and
> whatever other evasive language i would need to say so as to
> protect you from feeling challenged or threatened, because
> that's really _not_ my intention.  i have my own fish to fry...
>
> -bowerbird

Fish, eh? I thought I smelled something…

--
Dr. Drang
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Thomas Leitner]

On 2011-05-17 19:49 -0400 Michel Fortin wrote:
> What we really need is an effort in the style of HTML5's HTML parsing
> algorithm which provides an unambiguous definition of how things
> should be parsed. Heck, I started one a while ago for Markdown Extra,
> first by creating a tool to be able to evaluate what each
> implementation do when encountering an edge case (Babelmark, which is
> now hosted at ), then by starting
> writing such a specification (see
> ). Then I stopped because I
> realized it'd be too long and that I had many more interesting
> projects I could do in that free time.

You may also look at the syntax specification for kramdown (see
) which *should* provide an
unambiguous reference to how kramdown parses a Markdown (kramdown)
document.

-- Thomas
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

slept on this, but decided to send anyway, make it a trilogy...

***

david said:
>Well, then why don't you do it?

i've got some other fish to fry right now, in my own project,
but i will get around to tables soon enough with that myself,
and i'll be very happy to show people the results when i do...

and here are some of the "challenges" i'll want to try to handle:
>http://www.pgdp.net/phpBB2/viewtopic.php?t=4311&start=0
>http://www.pgdp.net/wiki/Formatting_Examples/Gallery_of_Table_Layouts

***

rob said:
>with all due respect, it's more than a little arrogant for 
>anyone to insist that they got it perfect the first time (1.0.1). 

well, gruber is well-known for being arrogant, but i do believe
that he has never insisted, or even claimed, he got it all "perfect".
and besides, the current charge is _neglect_, and not _arrogance_.

but all of that is a dodge as well.   gruber isn't really the factor here.
the _real_ problem is that there's several different implementations,
and they differ between each other, and none of 'em is significantly
better than the others, so none of them can overcome the stalemate.

i repeat:   it has nothing to do with gruber.   nothing at all.   really.
the only thing gruber could do is bless a successor.   and he won't.


>The idea of Markdown, not the implementation, is what's special.

nope.   lots of other people had "the idea" long before gruber.

indeed, "structured text" -- from which "restructured text" was
derived -- dates back to the 1990s, and was a contender against
the likes of .sgml.   if tim berners-lee would have been smarter,
he woulda chosen light-markup instead of going the other way.
but he had the notion that he wanted to follow ted nelson, so he
went for the "hypertext" model instead, and botched everything,
including all of the brilliant things that nelson _actually_ meant...

gruber gets the markdown attention because gruber gets attention.

but if all of you implementers got yourselves _around_ a table and
decided to develop "markaround" to go _around_ gruber, you could.

if you all agreed, amongst yourselves, gruber doesn't have enough
power -- or programming chops, or fame -- to thwart all of you...

the question is whether you'd rather be big fish in your own ponds,
in the backchannels of the lake of gruber, or go swim in the ocean.
of course, pandoc might just sweep you all into the ocean anyway...

and once again, none of this is a dig.   i haven't shared my own z.m.l.
with the world because i want to retain control over it, so that _my_
implementation is the _only_ one, so it is canonical, and therefore
there is absolutely no confusion about what the whole thing means.
with markdown, though, you do not have the luxury of such clarity...

***

michel said:
>What we really need is an effort in the style of HTML5's HTML 
>parsing algorithm which provides an unambiguous definition 
>of how things should be parsed.

that's right.


>Heck, I started one a while ago for Markdown Extra
>...
>Then I stopped because I realized it'd be too long and that I had
>many more interesting projects I could do in that free time. 

the other thing is that you were doing the task as the lead actor...
this effort will only work if it's a collaboration amongst all of you.
and each of you is probably going to have to give something up...
(unless you can find a sharp way to tease out all the ambiguities.
which, if you _can_ do that, will be the best solution for everyone.)


>Still, thanks for your analysis. It's refreshing to have 
>an outsider's opinion one time in a while. 

hey, who you calling "an outsider"?   i was researching light-markup
years before gruber and swartz came along.   this is my house, and
you kids better stop playing on my lawn...   outsider my ass! ;+)

seriously, though, markdown has been great for light-markup, and
i sincerely hope that you guys move markaround to the next level...

***

drang said:
>Fish, eh? I thought I smelled something…

you funny!:+)

but if you sincerely want to "call" it, you can.

i have promised to release my app when i get
100 people signed-up on this web-page here:
>http://jaguarps.blogspot.com/2011/04/blog-post_14.html

once i put it out in the world, you can criticize it
to the depths and heights of your heart's desire.

yes, i'm sittin' here, right on the edge of the dunk-tank,
daring you to step up and fire a hardball at the target...

***

albert said:
>Extensions address the question of limited scope, and 
>if they are to grow useful, it seems reasonable to inform them 
>with a more abstract purpose; e.g., enriching plain text with 
>logical structure, rather than making macros for html. 

that's quite astute.

***

thomas said:
>You may also look at the syntax specification for kramdown

you've done a very good job, thomas, really a smashup job...

my reservation is based on my reaction that "this isn't simpl

Re: Proposed table specification (long!)

[David Parsons]

On May 18, 2011, at 10:21 AM, bowerb...@aol.com wrote:



>   The idea of Markdown, not the implementation, is what's special.

nope.  lots of other people had "the idea" long before gruber.


   I believe that you misunderstand the argument here.   "The idea"
is not ascii formatting, it's the particular type of ascii formatting.
Markdown tries to take advantage of existing methods of ascii formatting
found in mail and usenet news, and tries to avoid lunging off into
apl-style symbol soup for markup.

   It's a considerable bonus that Mr. Gruber isn't constantly tweaking
the language definition, and users who start using markdown *now* will
still be able to use it two years down the line w/o having to retrain
themselves.


but if all of you implementers got yourselves _around_ a table and
decided to develop "markaround" to go _around_ gruber, you could.


   You mean like the way there's a common extension for definition
lists?  Or like there's a common extension for tables?I'm not
sure just what you're arguing against or for, unless it's the tyranny
of sticking to a standard.


and once again, none of this is a dig.  i haven't shared my own z.m.l.
with the world because i want to retain control over it,


   I had a vanity markup language once, too.  I'm happier using one  
that

can be found elsewhere; The markdown that I find on iOS apps is the
markdown I find on Github is the markdown I find on Reddit is the
markdown I find on my own web pages.



>   Still, thanks for your analysis. It's refreshing to have
>   an outsider's opinion one time in a while.

hey, who you calling "an outsider"?  i was researching light-markup
years before gruber and swartz came along.  this is my house, and
you kids better stop playing on my lawn...  outsider my ass!; 
+)


seriously, though, markdown has been great for light-markup, and
i sincerely hope that you guys move markaround to the next level...

***

drang said:
>   Fish, eh? I thought I smelled something…

you funny!   :+)

but if you sincerely want to "call" it, you can.

i have promised to release my app when i get
100 people signed-up on this web-page here:
>   http://jaguarps.blogspot.com/2011/04/blog-post_14.html

once i put it out in the world, you can criticize it
to the depths and heights of your heart's desire.

yes, i'm sittin' here, right on the edge of the dunk-tank,
daring you to step up and fire a hardball at the target...

***

albert said:
>   Extensions address the question of limited scope, and
>   if they are to grow useful, it seems reasonable to inform them
>   with a more abstract purpose; e.g., enriching plain text with
>   logical structure, rather than making macros for html.

that's quite astute.

***

thomas said:
>   You may also look at the syntax specification for kramdown

you've done a very good job, thomas, really a smashup job...

my reservation is based on my reaction that "this isn't simple".

that might be the way you've explained it.  (like michel's work,
your documentation seems to be aimed at the _format_wonks,_
who care about "block level versus span level" and such things.)

or it might be that the underlying framework is just too difficult.
(specifically, i wonder if all the hassles of "lazy syntax linewrap"
outweigh the convenience...  in my own work, i had to offer that
-- as project gutenberg files have mid-paragraph linebreaks --
but i worked out a way that it doesn't have to be quite so hard.)

so i just can't tell if it's the documentation or the framework, but
either way, if you can't find a more simple way to explain all of it
to ordinary people, i'm afraid you ain't gonna get a lot of uptake.

-bowerbird
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 18, 2011, at 10:21 AM, bowerb...@aol.com wrote:


but all of that is a dodge as well.  gruber isn't really the factor  
here.

the _real_ problem is that there's several different implementations,
and they differ between each other, and none of 'em is significantly
better than the others, so none of them can overcome the stalemate.


   What stalemate?It's not as if extensions don't exist (tables,
definition list support) and it's not as if the various implementations
don't converge upon the same extensions over time.




>   The idea of Markdown, not the implementation, is what's special.

nope.  lots of other people had "the idea" long before gruber.



I believe you misunderstand what's meant by "the idea"; there
have been quite a few klunky and horrible ascii markup languages
out there, but markdown tries to stick to the sort of formatting
that was already found in mail and usenet news messages.

Not having do so apl-style token soup or html with character
substitution ([i]...[/i] instead of ..., for example) to
prettify your text is one of the reasons that markdown is actually
popular with users, most of who don't seem to care very much
that you can't use markdown for extra-fancy formatting, but who
do like it that they can do routine formatting without making their
fingers or eyes explode.


decided to develop "markaround" to go _around_ gruber, you could.


I'm perfectly happy to support regular markdown with extensions.
I like being able to go from iOS apps to Reddit to Github to my
own web pages and use basically the same markdown.


i haven't shared my own z.m.l.
with the world



I had a vanity markup language once, too.  I found something  
better.




that might be the way you've explained it.  (like michel's work,
your documentation seems to be aimed at the _format_wonks,_
who care about "block level versus span level" and such things.)


If you're defining how a language works, you need to aim it at
the technically competent.If you want to explain it to a user,
you can use a help sidebar like the markdown dingus uses.  Different
audiences want different information.


-david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Chinyoka on Macbook]

Thanks for the great publishing system but I failed to add my comment to the 
already 89 ones I saw due to the verification code. Tried the audio one but to 
no joy, so hey I don't know how on earth I can add my signature to be the 90th. 
But I find that promising and just wonder whether it would work on Mac as well. 

I am also wondering whether there would be a way to split a document into many 
pages. I checked with other Markdown implementations and wish they would have a 
way to split a document into pages: for instance, Cramdown looked like it could 
if Thomas wanted to make it one of those options you can put between those 
sharp brackets and colons.

Currently, I am using PHP Markdown Extra for my web publishing, but want a 
solid desktop option. I sometimes wish there were a desktop version, whether 
command line or GUI, that would work like that PHP Markdown Extra.
So I hope your solution may be the answer to this. 
Anyway, it looks like Markdown in 2011 is heading for exciting moments with or 
without Gruber's blessing.


Thanks
Ishe

Mobile number: +263 772 930 422
WEB URL: www.chinyoka-educational.com
Skype ID: sunshinechinyoka

On 18 May,2011, at 7:21 PM, bowerb...@aol.com wrote:

> slept on this, but decided to send anyway, make it a trilogy...
> 
> ***
> 
> david said:
> >   Well, then why don't you do it?
> 
> i've got some other fish to fry right now, in my own project,
> but i will get around to tables soon enough with that myself,
> and i'll be very happy to show people the results when i do...
> 
> and here are some of the "challenges" i'll want to try to handle:
> >   http://www.pgdp.net/phpBB2/viewtopic.php?t=4311&start=0
> >   http://www.pgdp.net/wiki/Formatting_Examples/Gallery_of_Table_Layouts
> 
> ***
> 
> rob said:
> >   with all due respect, it's more than a little arrogant for 
> >   anyone to insist that they got it perfect the first time (1.0.1). 
> 
> well, gruber is well-known for being arrogant, but i do believe
> that he has never insisted, or even claimed, he got it all "perfect".
> and besides, the current charge is _neglect_, and not _arrogance_.
> 
> but all of that is a dodge as well.  gruber isn't really the factor here.
> the _real_ problem is that there's several different implementations,
> and they differ between each other, and none of 'em is significantly
> better than the others, so none of them can overcome the stalemate.
> 
> i repeat:  it has nothing to do with gruber.  nothing at all.  really.
> the only thing gruber could do is bless a successor.  and he won't.
> 
> 
> >   The idea of Markdown, not the implementation, is what's special.
> 
> nope.  lots of other people had "the idea" long before gruber.
> 
> indeed, "structured text" -- from which "restructured text" was
> derived -- dates back to the 1990s, and was a contender against
> the likes of .sgml.  if tim berners-lee would have been smarter,
> he woulda chosen light-markup instead of going the other way.
> but he had the notion that he wanted to follow ted nelson, so he
> went for the "hypertext" model instead, and botched everything,
> including all of the brilliant things that nelson _actually_ meant...
> 
> gruber gets the markdown attention because gruber gets attention.
> 
> but if all of you implementers got yourselves _around_ a table and
> decided to develop "markaround" to go _around_ gruber, you could.
> 
> if you all agreed, amongst yourselves, gruber doesn't have enough
> power -- or programming chops, or fame -- to thwart all of you...
> 
> the question is whether you'd rather be big fish in your own ponds,
> in the backchannels of the lake of gruber, or go swim in the ocean.
> of course, pandoc might just sweep you all into the ocean anyway...
> 
> and once again, none of this is a dig.  i haven't shared my own z.m.l.
> with the world because i want to retain control over it, so that _my_
> implementation is the _only_ one, so it is canonical, and therefore
> there is absolutely no confusion about what the whole thing means.
> with markdown, though, you do not have the luxury of such clarity...
> 
> ***
> 
> michel said:
> >   What we really need is an effort in the style of HTML5's HTML 
> >   parsing algorithm which provides an unambiguous definition 
> >   of how things should be parsed.
> 
> that's right.
> 
> 
> >   Heck, I started one a while ago for Markdown Extra
> >   ...
> >   Then I stopped because I realized it'd be too long and that I had
> >   many more interesting projects I could do in that free time. 
> 
> the other thing is that you were doing the task as the lead actor...
> this effort will only work if it's a collaboration amongst all of you.
> and each of you is probably going to have to give something up...
> (unless you can find a sharp way to tease out all the ambiguities.
> which, if you _can_ do that, will be the best solution for everyone.)
> 
> 
> >   Still, thanks for your analysis. It's refreshing to have 
> >   an outsider's opinion one time in a wh

re: Proposed table specification (long!)

[Bowerbird]

david said:
>"The idea" is not ascii formatting, 
>it's the particular type of ascii formatting.

there's nothing special about "the particular type"
of ascii formatting represented by markdown, as it
simply leveraged existing methods of ascii formatting 
found in e-mail and on usenet.   nothing unique there.
indeed, the important point was that it was pre-existing.


>Markdown tries to take advantage of existing methods 
>of ascii formatting found in mail and usenet news

right.   i'm glad we agree.

i used them too, and threw in huge dollop of the practices
already in use by project gutenberg for their e-texts, since
my specific aim was the p.g. library, as an existing corpus of
digitized books that would serve as content for my general
target, which was electronic-books across the full spectrum.

(that's still the focus of z.m.l. -- e-books, not web-pages.)

of course, project gutenberg also derived their conventions
from those used in e-mail, and usenet, and bulletin-boards.

so everyone, including markdown, gets these conventions
from the same place -- the humans who "invented" them
using the keyboards under their hands.   (and typewriters,
let us not forget; underscores, representing _italics_, came
from typewriters; so some of this stuff is really old-school.)

and it's probably good to remember that project gutenberg
was using this "intuitive" formatting way back in the 1990s.
when aaron swartz was really young, aged in single digits...

if markdown was the inspiration for you personally, i'm glad.

but markdown is assuredly _not_ where "the idea" came from.
it was already an old idea by the time markdown came about.


>I had a vanity markup language once, too.

i'll see if my users end up having a response to that charge...:+)

***

ishe said:
>I don't know how on earth I can 
>add my signature to be the 90th.

don't worry, ishe.   i will consider you signed up.   it is informal.


>But I find that promising

thanks.   i hope you find that i deliver on the promises as well.


>and just wonder whether it would work on Mac as well. 

mac first.   p.c. two seconds later.   linux if there's any demand.
(but since cory doctorow signed up, and sent a flock of people
to sign up as well, i guess i will have to resolve myself to that.)


>I am also wondering whether there would be a way 
>to split a document into many pages.

that will be a feature that i will provide sooner rather than later.

(the .epub format essentially demands that chapters be treated
as separate files, so a chapter-based split will be offered first.)

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

david said:
>If you're defining how a language works,
>you need to aim it at the technically competent.

if you want the masses to use it, you must aim there.


>Different audiences want different information.

true.   but trite.   to the point it might as well be wrong.

there are infinite audiences "possible", but there are
only 3 worth considering, and only 2 of those 3 matter.

and thomas and michel were aiming at "the format wonks",
who are the third group, the one that doesn't even matter.
they don't matter because they fail to add any real value.
that's why thomas and michel were just wasting their time,
in my humble opinion.   who cares what format wonks think?

so let's concentrate on the other two groups instead, ok?

users are crucial, because without them you are nothing.
and programmers matter, since you need implementers.

users need something simple, and hopefully unambiguous.
programmers need unambiguity, and it's best if it's simple.

if you make your thing simple _and_ unambiguous, bingo!

***

albert said:
>I imagine the emergence and vitality 
>of a standard syntax (among other things) would 
>benefit if everyone were familiar with this book: 

also astute.

but unduly circuitous.

usually i hate to give up my hard-fought trade secrets.
and the more big, and obvious, and brilliant, they are,
the more that i hate to give 'em up, precisely because
it is exactly that first step where most people go bad,
as evidenced right here by what albert said.   but still,
markdown and its implementers have suffered enough,
so please consider this to be my open-source gift to you:
the big secret is that all you must do is split the text on
blank lines, and then just decide what each segment is,
which will tell you how it needs to be tagged/formatted.
that's it, folks.   it ain't rocket science.   it's simple as pie.
reverse-engineer your syntax from that for unambiguity.
simple, and unambiguous.   that's all you need for bingo!

but bravo for bringing up bringhurst, mr. skye.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[David Parsons]

On May 19, 2011, at 6:08 PM, bowerb...@aol.com wrote:


and thomas and michel were aiming at "the format wonks",
who are the third group, the one that doesn't even matter.
they don't matter because they fail to add any real value.
that's why thomas and michel were just wasting their time,
in my humble opinion.  who cares what format wonks think?


   Okay, so you're trolling.   Well played, sir!But
perhaps it's not appropriate for this mailing list?


   -david parsons
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

david said:
>Okay, so you're trolling.

whoa.   now _that's_ certainly an ironic twist.

you demean me, repeatedly, and then have
the audacity to go accuse _me_ of "trolling",
all while you spin the conversation in circles...
that definitely takes some chutzpah, yes it do.

at any rate, david, if you think format wonks
add value to the equation, you can tell us how.
in the meantime, i'll stand by my assessment.

if anyone wants to get back on-topic, i'm game.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Christian Sciberras]

Not to nitpick, but your posts have every indication of a troll...

Perhaps you might want to change your writing style? :)

Chris.




On Fri, May 20, 2011 at 9:44 AM,  wrote:

> david said:
> >   Okay, so you're trolling.
>
> whoa.  now _that's_ certainly an ironic twist.
>
> you demean me, repeatedly, and then have
> the audacity to go accuse _me_ of "trolling",
> all while you spin the conversation in circles...
> that definitely takes some chutzpah, yes it do.
>
> at any rate, david, if you think format wonks
> add value to the equation, you can tell us how.
> in the meantime, i'll stand by my assessment.
>
> if anyone wants to get back on-topic, i'm game.
>
> -bowerbird
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

i said:
>if anyone wants to get back on-topic, i'm game.

and now i add that if your posts are not on-topic
(i'm looking at you, christian), i am _not_ game...

so don't bother trying to play me.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Christian Sciberras]

Yeah, let's all get back on topic, 'coz bowerbird said so.

What was the topic again? Oh, trolling on how everyone want to make his own
personal markdown spec.
I've nothing to add than that it's their own decision.

Chris.



On Fri, May 20, 2011 at 9:56 AM,  wrote:

> i said:
> >   if anyone wants to get back on-topic, i'm game.
>
> and now i add that if your posts are not on-topic
> (i'm looking at you, christian), i am _not_ game...
>
> so don't bother trying to play me.
>
> -bowerbird
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Thomas Leitner]

On 2011-05-20 03:44 -0400 bowerb...@aol.com wrote:
> at any rate, david, if you think format wonks
> add value to the equation, you can tell us how.
> in the meantime, i'll stand by my assessment.

The syntax specification for kramdown is complicated, sure, but trying
to explain the corner cases and how the implementation handles them is
just not that easy.

So, yes, the syntax spec is not aimed at the plain user, but the quick
reference is. It's vastly simplified but provides a quick overview of
the available syntax. And if something doesn't quite work the way a
user expected, he/she can always have a look at the specific section in
the syntax specification, no need to look at the code! And the last
part (no need to look at the code) is one thing that I tried to
avoid with the syntax specification. It can be read by anyone and
doesn't require the knowledge of a certain programming language.

-- Thomas
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Yuri Takhteyev]

> the big secret is that all you must do is split the text on
> blank lines, and then just decide what each segment is,
> which will tell you how it needs to be tagged/formatted.
> that's it, folks.  it ain't rocket science.  it's simple as pie.

Wow. I wish I had realized this back in 2005 when I started working on
my Python implementation. All of those hours wasted, while all I had
to do was split the text on blank lines.

I think this deserves to be added to "The Collected Sayings of
Bowerbird." (Just google).

 - yuri
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[Seumas Mac Uilleachan]

I thought the topic was a proposed table specification? Like it says in 
the subject line? Somehow it ALL got off-topic.


On 05/20/2011 04:05 AM, Christian Sciberras wrote:

Yeah, let's all get back on topic, 'coz bowerbird said so.

What was the topic again? Oh, trolling on how everyone want to make 
his own personal markdown spec.

I've nothing to add than that it's their own decision.

Chris.



On Fri, May 20, 2011 at 9:56 AM, > wrote:


i said:
>   if anyone wants to get back on-topic, i'm game.

and now i add that if your posts are not on-topic
(i'm looking at you, christian), i am _not_ game...

so don't bother trying to play me.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net

http://six.pairlist.net/mailman/listinfo/markdown-discuss



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

yuri said:
>Wow. I wish I had realized this back in 2005 when 
>I started working on   my Python implementation. 
>All of those hours wasted, while all I had   to do was 
>split the text on blank lines. 

well, yes, it woulda saved you a few years of time, eh?

luckily, by 2008, you'd sensed that this was the solution,
judging by this passage you left on this listserve in march:
>   Let's first unambiguously specify how markdown text 
>ought to be parsed into paragraphs, quotes, lists, etc.
>Michel, do you want to do a first draft and circulate it?

michel did the first pass, on a draft which then... fell flat.

and now, 3 years after _that_, michel is currently saying:
>   What we really need is an effort in the style of 
>HTML5's HTML parsing algorithm which provides an 
>unambiguous definition of how things should be parsed

you guys can run around in circles all you like, until you
finally decide you're gonna work together to accomplish
this objective, and then, when you do, you can revisit my
advice, whereupon you'll find it is exactly what you need.

i'm _not_ telling y'all that you have a problem.   i have _no_
desire to do an intervention on you.   do what you like, guys.
it's jeff atwood who was telling you that you have a problem.
i say if you want to remain islands, i'm perfectly fine with it.

but if/when _you_ decide that you have a problem, well then
you will probably also realize that i've given you the solution.

because, after all, you'd seized upon the solution yourselves,
years ago; you just didn't realize that you had found the key.
(or, if you did realize it, you didn't use it to unlock the door.)

***

and i _invite_ you to add all of this to "the collected sayings".

except it hasn't been updated in a long time.   you know why?

because the guy who created it was in a long-running dispute
with me about how p.g. should proceed.   i said "light-markup"
and he said "t.e.i."   (as if volunteers at p.g. could handle t.e.i.)

finally, about a year back, he realized he was wrong all along.
he still won't _admit_ that, but he quietly shifted his efforts to
-- guess what -- light-markup, in the form of restructured text.

how does that saying go?

>"first they laugh at you,
>then they ignore you,
>then they fight you,
>then you win."

and how does that other saying go?

>he who laughs last
>laughs best.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Proposed table specification (long!)

[Bowerbird]

thomas said:
>   yes, the syntax spec is not aimed at the plain user, 
>but the quick reference is. It's vastly simplified

yes, the quick reference is much simpler, and thus better...

and we could discuss why, but my sense is that nobody here
really wants to talk about it any more, at least right now, so
i'm happy to wait until next year, when it comes up again...

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Proposed table specification (long!)

[tycho garen]

On Wed, May 18, 2011 at 08:28:53PM +0200, Chinyoka on Macbook wrote:
> I am also wondering whether there would be a way to split a document
> into many pages. I checked with other Markdown implementations and
> wish they would have a way to split a document into pages: for
> instance, Cramdown looked like it could if Thomas wanted to make it
> one of those options you can put between those sharp brackets and
> colons.

I take the view that markdown is really a text processing filter
rather than a publishing solution, so this feels very out of
scope. Perhaps something like emacs muse-mode (which I think has some
limited markdown functionality,) or just "the right Makefile" could do
the processing you want to get multi-page output. In short: it's a
good feature but enough depends on the rest of your publishing
process/solution, so look there. 

> Currently, I am using PHP Markdown Extra for my web publishing, but
> want a solid desktop option. I sometimes wish there were a desktop
> version, whether command line or GUI, that would work like that PHP
> Markdown Extra.  So I hope your solution may be the answer to this.
> Anyway, it looks like Markdown in 2011 is heading for exciting
> moments with or without Gruber's blessing.

I used PHP Markdown Extra for years with a WordPress site. When I
stopped that, I had a bunch of vanilla markdown with footnotes (and
maybe images?) in the markdown extra. I continue to write text in the
same way, and have been processing this text both on the web and
locally using: Maruku (abandoned for speed reasons, but it's good for
LaTeX conversions and one-offs,) and MultiMarkdown pretty much without
error. I'm given to understand that python markdown and pandoc would
also do what you want in terms of the extra syntax... 

Hope that helps, 

tycho

-- 
tycho(ish) @
 ga...@tychoish.com
  http://tychoish.com/
  http://criticalfutures.com/
  "don't get it right, get it written" -- james thurber


pgpcLD5qlwpTo.pgp
Description: PGP signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss