On Jun 25, 2009, at 6:30 AM, Sherwood Botsford wrote:
1. Editing with non-elastic tab stops? While Nick's idea is good,
the
number of editors that support it is small. Editors are a religious
issue.
I doubt that people will switch editors in order to use MMD tables.
And it's not just ed
On Jun 24, 2009, at 4:27 PM, Simon Bull wrote:
Okay, thanks for your input, David.
Tables with lots of narrow columns are not so rare they can be
dismissed;
they are useful for matrices of numbers, for example.
Yeah, but merging a given row of them into one column is much less
common.
1. Editing with non-elastic tab stops? While Nick's idea is good, the
number of editors that support it is small. Editors are a religious issue.
I doubt that people will switch editors in order to use MMD tables.
2. I would like to see an option for a non-white character. I've been
burned a fe
I can't say that I find this proposal to be perfect, but to me this was
one of the more compelling emails in this thread.
I have been having my own internal conversation about how to rewrite the
MMD table syntax. My personal goals were to find a way to minimize the
markup, make it more readab
Okay, thanks for your input, David.
Tables with lots of narrow columns are not so rare they can be dismissed;
they are useful for matrices of numbers, for example.
How about an (entirely optional) addition to the existing multimarkdown pipe
syntax, specifically for cells which span many cols? A
On Jun 23, 2009, at 10:24 PM, Simon Bull wrote:
Personally, I would prefer to use exactly one table syntax, so long
as it
_works_.
Yeah, that would be my preference, as well, where "_works_" eq "is
legible as plain text and parses properly."
Using one pipe per col to span is okay for sma
Personally, I would prefer to use exactly one table syntax, so long as it
_works_.
Using one pipe per col to span is okay for small number of columns to span,
though it doesn't scale elegantly, as in the following example;
| This cell spans 9 cols, and therefore has 9 pipes |
|
On Jun 23, 2009, at 6:45 PM, Waylan Limberg wrote:
Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3]
all support definition lists using the colon as well. And that's only
the ones I'm familiar with. There may be others. The point is, I think
this is an established enough syn
On Jun 23, 2009, at 6:43 PM, Simon Bull wrote:
Explicit row markers do _work_, but they are too verbose for my
liking.
They are more work to write, and don't read as cleanly. The colon
syntax
_works_ too, and it is cleaner, and I think having a source document
which
is natural to write, a
On Tue, Jun 23, 2009 at 9:45 PM, Waylan Limberg wrote:
[snip]
> colon. In fact, it would seem reasonable to expect that the very
> implementations which correctly support definition lists (using
> colons) would be the first to implement any new alternate table
> syntax, whether it uses colons or no
On Tue, Jun 23, 2009 at 5:01 PM, David E. Wheeler wrote:
> On Jun 22, 2009, at 9:01 PM, Simon Bull wrote:
>
>> * The colon is used more commonly in content than the pipe, and,
>> * ':' is markdown syntax denoting a definition list.
>
> Actually, it's in used for a definition list in MultiMark
My apologies, I didn't read David's post correctly. After looking at it
more closely, I agree with the previous posts; a leading pipe followed
vertically by trailing colons is much better than the other way around, so
it should have looked like this:
Col A| Col B | Col C
-
On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote:
And here's what I believe you meant:
|Col A| Col B | Col C
==+=+==+=
1 | A1 |B1|C1
--+-+--+-
| a2 contains | b2 | c2
| some long & | b2 |
On Jun 22, 2009, at 9:01 PM, Simon Bull wrote:
* The colon is used more commonly in content than the pipe, and,
* ':' is markdown syntax denoting a definition list.
Actually, it's in used for a definition list in MultiMarkdown.
Markdown does not support definition lists. I have a [re
On Tue, Jun 23, 2009 at 2:38 PM, Michel Fortin wrote:
[snip]
> Are you sure this syntax is so intuitive? I was certain (for about 5
> minutes) that you meant the colons to continue the cell from the previous
> line, not start a new cell, despite the weird result. What David Wheeler
> proposed seem
Le 2009-06-23 à 0:01, Simon Bull a écrit :
Thus, text may be continued over any number of lines in a table
body, like
this;
|Col A| Col B | Col C
---+-+--+-
1 | A1 |B1|C1
: a2 contains : b2 : c2
: some long & : b2
Hello List,
While translating documents in markdown, I've noticed that it is often
necessary to continue table cell text on the following line, especially when
limited to a narrow column, and especially in table headers. Unfortunately,
this is impossible with the existing table syntax, which int
17 matches
Mail list logo
