tag:support.fletcherpenney.net,2013-02-12:/discussions/suggestions/10-extended-table-syntaxMultiMarkdown: Discussion 2021-05-09T18:18:07Ztag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-07T19:09:26Z2013-06-07T19:09:27ZExtended Table Syntax<div><p>unfortunately my code-blocks didn't get parsed as markdown.
However, the advantage of "pipe style tables" (as i call them) is
that they don't need monospaced font. I hope you get the meaning of
my examples even unformated. You can copy them to plaintext and
insert the spaces to align the bars to get a better visual
representation.</p></div>jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-07T21:06:11Z2013-06-07T21:06:11ZExtended Table Syntax<div><p>Thanks for writing in with your proposal. Tables are a
complicated thing to extend. Everyone has their own pet idea, but
they are generally not very intuitive to people who didn't create
them.</p>
<p>I threw your post into MultiMarkdown Composer so I could
properly format the tables and be sure I was looking at what you
intended. The problem with the first two tables is that it's not
immediately clear to what the symbols are for, and it's easy at a
glance to miss that there are apostrophes in the second table. Now
arguably, that's good, since it's not distracting. But it would be
easy to mis-copy a table and then wonder why it wasn't looking like
you intended.</p>
<p>The "======" proposal may be feasible at first glance.</p>
<p>The proposal at the end for extending cells by using a number
would be really prone to error and is unlikely to be useful in real
life use. When reading the source, unfamiliar users would wonder
what the numbers mean.</p>
<p>I will think about the "====" proposal. I'll go ahead and reject
the "cell 7|" proposal. As to the first two ideas, it's unlikely
that I will implement them:</p>
<ul>
<li>
<p>It will be labor intensive to properly extend a parser to handle
multirow table cells. Perhaps not impossible, but ridiculously
complex. For example, a bold phrase that extends across two rows in
a table would be difficult to parse as bold. A list spanning
multiple rows of text would have to be tracked for indenting to
allow sublists. I could go on, but you probably begin to see how
much of a challenge this would be.</p>
</li>
<li>
<p>A rowspan marker by itself is simple, but as soon as I implement
it, somebody will use it for a multirow cell, and then wonder why
it doesn't work.</p>
</li>
<li>
<p>Even if I managed to do it, then there's the complexity of block
level elements inside a table across output formats (e.g. LaTeX,
ODF, etc.) This may or may not be feasible.</p>
</li>
<li>
<p>The reality is that it's not currently realistic to expect MMD
to support tables of arbitrary complexity.</p>
</li>
<li>
<p>I have never (or at least almost never) personally needed a
table to have more than I could accomplish with MMD as it stands.
And if I don't need something crazy, it's unlikely to make it into
MMD. If I want something, it's much more likely to get included,
even if it is crazy. ;)</p>
</li>
</ul>
<p>For those reasons, it's really unlikely that I will add
rowspan/multirow table cells now, or in the future. But I'll keep
your proposal in mind if I do.</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-11T14:51:25Z2013-06-11T14:51:25ZExtended Table Syntax<div><p>I understand that there are many different table formats. Pandoc
uses gridtables and whitespace tables (they call it simple tables),
for example. However, for pipe style tables (as i would call MD
extra style in general) i feel that there are not that many
options. At least i bave not seen another similar proposal. Of
course, i don't have to stick to the symbols i chose, just the
mechanism matters.</p>
<p>Adittionally, i think these features can be implemented on after
the other.</p>
<p>I chose "^" as the most logical symbol to point upwards. It's
easy to replace a "|" with a "^" to merge two cells without
breaking the rest of the table and vice versa.</p>
<p>I chose "'" on purpose to look similar to the pipe. It would be
visually easier to use no symbol at all, but this would require
monospaced font and white space align (the major drawback of
pandocs tables). The idea of extending cells downwards is not only
to allow block elements (maybe only later) but to ease writing
longer text into a cell without making the text table extremely
wide.</p>
<p>I dont know how exactly you are parsing the tables. Is it line
by line? I have coded the features in my js pandoc at github (the
online demo doesnt work, but offline works fine). Actually, parsing
these tables is a lot easier than similar features in grid tables
or whitespace tables! But yes, my code "waits" for the whole table
to be analysed before parsing each cells' content. Like that there
is also no problem with multirow cells.</p>
<p>Regards, jakov</p>
<p>Am 07.06.2013 um 23:06 schrieb "fletcher" <a href=
"mailto:tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com">
tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com</a>:</p></div>Jakobtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-12T15:36:37Z2013-06-12T15:36:37ZExtended Table Syntax<div><p>Jakob,</p>
<p>I suspect that adding proper syntax highlighting to a table
structure of this sort would be very difficult (though presumably
not impossible). One would have to compile the various lines into a
single table, pull out the text from extended cells to make a new
string of the contents of each cell, apply the parsing to determine
syntax highlighting needs, and then split the cell back into its
component lines so that the highlighting can be applied back into
the cell, which spans multiple lines. For example, I span of bold
that crosses two (or more) lines, would have to be split into
multiple bold spans to cover each of the contiguous strings.</p>
<p>It's a slightly different (and more complicated) problem than
just converting the text into HTML, and I have to consider both
aspects. Practically speaking, my guess is that it would not be
worth the time and effort, so something like MultiMarkdown Composer
would have to simply not apply any syntax highlighting inside
tables. It could still be used in the HTML/LaTeX output, of course,
but not in the editor itself.</p>
<p>That said, it's still an uphill battle to convince me to extend
the table syntax in this sort of a way. Don't get me wrong, I
understand that some people need complex tables. And I'm sure at
least one person has used each of the 10,000 unnecessary features
included in something like MS Word. But I strongly believe that the
beauty and power of Markdown is its simplicity. I am trying to hang
onto that in MMD as well. HTML and LaTeX both offer very powerful
table support, so in that sense complex tables are already
supported. At some point, the syntax used by a markup language to
provide all of these table features will approach the complexity of
the underlying HTML/LaTeX. So why not just use that instead? Table
support in MMD is not intended to cover every use case. But I think
it does a phenomenal job of covering simple tables that most
commonly come up in "regular" life (not for academics, or complex
business documents, etc.)</p>
<p>There may be the "perfect" hybrid syntax out there somewhere,
and I'm perfectly willing to keep looking at proposals. But the one
that is going to win me over is the one that is elegant, simple,
intuitive, unambiguous, and doesn't look like computer markup. It's
a tall order... In my opinion, no one has adequately solved this
problem yet.</p>
<p>Fletcher</p>
<p>On Jun 11, 2013, at 10:51 AM, Jakob <a href=
"mailto:tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com">
tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com</a>
wrote:</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-14T12:53:29Z2013-06-14T12:53:29ZExtended Table Syntax<div><p>I have to admit, that I have not thought about syntax
highlighting and i<br>
admit that it doesn't look easy. However, I think that any table
syntax<br>
that is sufficiently intuitive will have this problem. I don't
think it<br>
is more convenient to have really long table cells break the line
like that:</p>
<table>
<tr>
<th>ibewui asdf</th>
<th>poiusa dsaf</th>
<th>lkjna eaf</th>
</tr>
<tr>
<td>Lorem ipsum dolor sit amet, cu cibo minim his.</td>
<td>Nostro</td>
<td></td>
</tr>
<tr>
<td>..sapientem vituperatoribus ei has.</td>
<td>Consul iracundia</td>
<td></td>
</tr>
<tr>
<td>..repudiandae duo eu.</td>
<td></td>
<td></td>
</tr>
<tr>
<td>No legimus incorrupte adversarium duo.</td>
<td>Ius mutat</td>
<td></td>
</tr>
<tr>
<td>..molestiae ut.</td>
<td>Argumentum adversarium no sit.</td>
<td></td>
</tr>
</table>
<p>I also think that it might be even more difficult to have
text-editors<br>
or markdown editors break the lines at multiple positions like
this:</p>
<table>
<tr>
<th>ibewui asdf</th>
<th>poiusa dsaf</th>
<th>lkjna eaf</th>
</tr>
<tr>
<td>Lorem ipsum</td>
<td>Nostro sapientem</td>
<td>Consul iracundia</td>
</tr>
</table>
<p>.. dolor sit ..vituperatoribus ..repudiandae duo ..amet, cu cibo
..ei has. ..eu.<br>
..minim his. .. ..<br>
| No legimus | Ius mutat | Argumentum | ..incorrupte ..molestiae
ut. ..adversarium no<br>
..adversarium .. ..sit.</p>
<p>On the other hand, it would be cool to have this for writing
--<br>
independently of whether this gets saved to the source file or not.
The<br>
drawback would be that other editor (who are not capable of doing
so)<br>
will get very long lines again.</p>
<p>I would nevertheless argue, that Markdown is intended to be a
kind of<br>
syntax highlighting in itself. Markdown should even be useable
with<br>
notepad.exe or any other bad texteditor. Therefore i think it would
be<br>
only a little drawback if tables don't have highlighting in
multiple<br>
rows. The first rows (or non-extended cells) could still have
normal<br>
highlighting. Only breaking syntax or syntax in the following
lines<br>
(marked with either "^" or " ' ") would be omitted. Again, you
could introduce the features one by one, i.e. no syntax higlighting
in<br>
extended cell at first but maybe later.</p>
<p>My point of writing tables even in slightly more complex for
into a<br>
markdown file is that you then have one source file. Can you put an
HTML<br>
table into a MMD file and get LaTex output for that table?</p>
<p>Did you get any other table syntax proposals recently ? Could
you point<br>
me to any of them? I'd really like to see their advantages and
drawbacks.</p></div>Jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-14T13:47:27Z2013-06-14T13:47:27ZExtended Table Syntax<div><p>(i forgot to mention something:)</p>
<p>I have also thought about syntax for Pandoc's "simple tables"
and "grid<br>
tables". I've noted my concepts here:<br>
<a href=
"https://github.com/jakov/js-pandoc/blob/master/concepts.md">https://github.com/jakov/js-pandoc/blob/master/concepts.md</a>
and some of<br>
it is (partially buggy) already working, as you can see here:<br>
<a href=
"http://jakov.github.io/js-pandoc/demo.html">http://jakov.github.io/js-pandoc/demo.html</a></p>
<p>Coding the MMD-like extended tables is a lot easier than the
fixed-width<br>
tables. What I want to point you to is that neither these two
other<br>
syntax styles would allow for easy syntax highlighting.</p>
<p>Regards,<br>
jakov</p></div>Jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-14T18:04:39Z2013-06-14T18:04:39ZExtended Table Syntax<div><blockquote>
<p>My point of writing tables even in slightly more complex for
into a markdown file is that you then have one source file. Can you
put an HTML table into a MMD file and get LaTex output for that
table?</p>
</blockquote>
<p>If you use the XSLT to convert HTML -> LaTeX (the only way to
do LaTeX in MMD 2, but not really used by most people in MMD 3/4),
you could use HTML tables to create LaTeX tables, but the tables
still had to be fairly simple. I suppose one could update the XSLT
to handle more complex tables thought.</p>
<p>You are correct that complex tables written in HTML will not
work in LaTeX, and vice-versa. But the sample complexities will
sometimes have to be addressed when converting to RTF,
OpenDocument, Word, etc.</p>
<blockquote>
<p>Did you get any other table syntax proposals recently ? Could
you point me to any of them? I'd really like to see their
advantages and drawbacks.</p>
</blockquote>
<p>I occasionally get emails with table syntax proposals. The ones
that are public would either be on the support site or the
MultiMarkdown discussion list.</p>
<pre>
<code>http://groups.google.com/group/multimarkdown/
http://support.fletcherpenney.net/</code>
</pre>
<p>F-</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-14T18:29:07Z2013-06-14T18:29:07ZExtended Table Syntax<div><p>(The "dingus" doesn't seem to do anything.)</p>
<p>As to the many ideas about tables in the
<code>concepts.md</code> file, a few thoughts.</p>
<ul>
<li>
<p>perhaps a slight exaggeration, but there are almost as many
syntaxes for tables as the original Markdown has for all of its
features... ;)</p>
</li>
<li>
<p>it would be very difficult for multiple developers to correctly
implement these features in multiple programming languages, leading
to even more of a "tower of babel" effect in the "Markdown
family"</p>
</li>
<li>
<p>I suspect this is yet another "scratching one's own itch" area
--- I just don't care that much about complex tables. I rarely need
them. I think they are often overused and unnecessary, but that's
clearly a sweeping overgeneralization that is not always true. I
doubt that many current "Markdown family" developers will have the
motivation/interest in implementing all of these features in the
"leading" variants. Which means they will be relegated to second
tier Markdown variants that lack support in most tools</p>
</li>
<li>
<p>Some of the proposals are very unambiguous (e.g. Grid Style).
However it would be a nightmare to type by hand. What about when
you decide to insert a line, or a cell, etc.?</p>
</li>
<li>
<p>I think the part of the difficulty is trying to apply a
successful solution to a problem it wasn't designed for. Markdown,
and it's descendants, are fantastic for text. Those of us who get
it realize that it orders of magnitude better than Word for most
documents. That said, Markdown would not be particularly useful for
programming a spreadsheet, or drawing a blueprint. In this case,
writing tables brings a different set of problems and design needs
than straight text. For most of us, writing text in Markdown is
<em>easier</em> than writing in Word. It's more intuitive. It's
faster. It's more "cross-platform." For writing a complex table,
however, I suspect that using Word, OpenOffice, Excel, Pages, etc.
would be easier. You want cells that expand to fit their content.
You want to be able to merge/split cells, etc. It's really hard to
do that in a plain text editor by hand. Imagine writing one of
these on your cell phone.</p>
</li>
<li>
<p>My personal opinion is that a bunch of us can spend a lot of
time creating ever more complex ways of trying to represent a table
of arbitrary complexity in plain text. Some solutions will be
better than others. But my suspicion is that none will really ever
be good enough, when measured not just on their ability to mimic a
complex table as ASCII-art, but instead when measured on their ease
of creation by a human using a dumb text editor (e.g. Notepad). I'm
not convinced that most of the proposals are easier than the
traditional standard (e.g. Word).</p>
</li>
<li>
<p>My proposal would instead be to try and redefine the problem.
What is the exact problem you are trying to solve? If you were
starting from scratch, how would you solve that problem? Is trying
to shoehorn this into Markdown/MultiMarkdown/Pandoc/etc. the best
approach. Do we need something else? What would that something else
look like? Embedding an image of the table? Something else? I think
something "revolutionary" is more likely to be successful than
something "evolutionary" in this arena.</p>
</li>
</ul>
<p>F-</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-15T20:04:09Z2013-06-15T20:04:09ZExtended Table Syntax<div><div>
<div>
<div>Sorry, there's an error in safari. It works in Firefox. I'll
try to fix this soon.</div>
<div> </div>
<div>I understand that some of my ideas are not comfortable in in
all syntaxes. I was trying to find an implementation for each of
the features for all three styles. Each of them has some
advantages.</div>
<div> </div>
<div>* The most obvious advantage of pipe style is that it works in
non-monospaced fonts and no sophisticated editor.</div>
<div>* Blank tables lack distrackting bars and has a relatively
intuitive way of using multiline content for cells.</div>
<div>* Grid-tables support containing any block element even tables
inside tables inside tables etc. and rowspan as well as colspan
would be intuitive to create.</div>
<div> </div>
<div>I do favour Pipe style as it is easy to write and has a "lazy
mode". Adding cells and lines is easy, as you say. I had a look at
your MMD composer and i think tables got badly scrambled in source
view there. I love the elastic tabstops however. I think you should
make typing "tab" inside a table add "tab" plus pipe, not only pipe
as this would largely benefit the layout of the table. Also it
seems to be not even possible to really type a "tab" inside a
table, so not even beautifying the source manually works. It would
add that brwaking the lines at the elastic tabstops wouldn't seem
so illogical, as it would make sense also in different
environments, not only tables. It would be strange to have tables
behave differently, but having all text behave the same would be
natural.</div>
<div> </div>
<div>I think that Pipe tables with my syntax for multiline cells
would make it superior to blank tables. Enabling nested tables in
Pipe style would still be difficult yet not impossible: escaped
pipes would be replaced by normal pipes for parsing:</div>
<div> </div>
<div>
<div>| testing nesting| table |<br>
|----------------|-------|<br>
| \|nest\|test\| | some |<br>
' \|----\|----\| ' text '<br>
' \|one \|two \| ' here '</div>
<div> </div>
<div>This looks somewhat ugly, but as you point out it would be
used seldomly. Escaping a pipe also at the second level (if it
could otherwise be interpreted as part of a table) would need \\\|
i guess. With the ability to do whatever you want inside a pipe
table, i think it's syntax would be superior also to a possible
future complex gridtable style.</div>
<div> </div>
<div>The "tower of babel" in Markdown syntaxes is already built.
Just look at how Pandoc and MMD handle citations differently, how
MDX includes abbreviations. Different fenced code-blocks. There are
syntaxes for forms. Strikeout, superscript and subscript. I think
there are already so many features out there that only very few
will limit themselves to pure pure MD. Why not push the syntax as
long as it's unobstrusive?</div>
<div> </div>
<div>I also agree that especially for larger tables editing in
Excel (aut simil) is easier. However, also Excel supports exporting
and importing comma- or tab-seperated values. But even CSV lacks
rowspan and colspan.</div>
<div> </div>
<div>Regards, jakov</div>
</div>
<div> </div>
<div>
<div name="quote">
<div><b>Gesendet:</b> Freitag, 14. Juni 2013 um 20:29 Uhr<br>
<b>Von:</b> fletcher
<tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com><br>
<b>An:</b> jakov@gmx.at<br>
<b>Betreff:</b> Re: Extended Table Syntax [Suggestions
#10]</div>
<div name="quoted-content"><!--pre { width: 92.0%; margin:
10.0px 2.0%; padding: 5.0px 2.0%; background: rgb(239,239,239);
border: 1.0px solid rgb(214,214,214); } -->
<table width="100%">
<tr>
<td>
<p>// Please reply above this line<br>
==================================================</p>
<p><b>From</b>: fletcher (Support staff)</p>
<div>
<p>(The "dingus" doesn't seem to do anything.)</p>
<p>As to the many ideas about tables in the `concepts.md` file, a
few thoughts.</p>
<p>* perhaps a slight exaggeration, but there are almost as many
syntaxes for tables as the original Markdown has for all of its
features... ;)</p>
<p>* it would be very difficult for multiple developers to
correctly implement these features in multiple programming
languages, leading to even more of a "tower of babel" effect in the
"Markdown family"</p>
<p>* I suspect this is yet another "scratching one's own itch" area
--- I just don't care that much about complex tables. I rarely need
them. I think they are often overused and unnecessary, but that's
clearly a sweeping overgeneralization that is not always true. I
doubt that many current "Markdown family" developers will have the
motivation/interest in implementing all of these features in the
"leading" variants. Which means they will be relegated to second
tier Markdown variants that lack support in most tools</p>
<p>* Some of the proposals are very unambiguous (e.g. Grid Style).
However it would be a nightmare to type by hand. What about when
you decide to insert a line, or a cell, etc.?</p>
<p>* I think the part of the difficulty is trying to apply a
successful solution to a problem it wasn't designed for. Markdown,
and it's descendants, are fantastic for text. Those of us who get
it realize that it orders of magnitude better than Word for most
documents. That said, Markdown would not be particularly useful for
programming a spreadsheet, or drawing a blueprint. In this case,
writing tables brings a different set of problems and design needs
than straight text. For most of us, writing text in Markdown is
*easier* than writing in Word. It's more intuitive. It's faster.
It's more "cross-platform." For writing a complex table, however, I
suspect that using Word, OpenOffice, Excel, Pages, etc. would be
easier. You want cells that expand to fit their content. You want
to be able to merge/split cells, etc. It's really hard to do that
in a plain text editor by hand. Imagine writing one of these on
your cell phone.</p>
<p>* My personal opinion is that a bunch of us can spend a lot of
time creating ever more complex ways of trying to represent a table
of arbitrary complexity in plain text. Some solutions will be
better than others. But my suspicion is that none will really ever
be good enough, when measured not just on their ability to mimic a
complex table as ASCII-art, but instead when measured on their ease
of creation by a human using a dumb text editor (e.g. Notepad). I'm
not convinced that most of the proposals are easier than the
traditional standard (e.g. Word).</p>
<p>* My proposal would instead be to try and redefine the problem.
What is the exact problem you are trying to solve? If you were
starting from scratch, how would you solve that problem? Is trying
to shoehorn this into Markdown/MultiMarkdown/Pandoc/etc. the best
approach. Do we need something else? What would that something else
look like? Embedding an image of the table? Something else? I think
something "revolutionary" is more likely to be successful than
something "evolutionary" in this arena.</p>
<p>F-</p>
</div>
</td>
</tr>
<tr>
<td>
<p>Having trouble reading this? View this discussion online:
<a href=
"http://support.fletcherpenney.net/discussions/suggestions/10-extended-table-syntax">
Extended Table Syntax</a>.</p>
<p>Reply with #ignore to stop receiving notifications for this
discussion.</p>
</td>
</tr>
</table>
</div>
</div>
</div>
</div>
</div></div>Jakobtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-16T00:52:19Z2013-06-16T00:52:19ZExtended Table Syntax<div><p>Jakob,</p>
<p>Thanks for writing.</p>
<p>No worries about browser compatibility. I was actually using
Chrome, but might be the same issue as Safari.</p>
<p>Why do you say tables got "badly scrambled?" in Composer. When
you type a tab inside a table, it does add a tab and a pipe so that
the table aligns properly. In fact, you can create a simple table
only having to type the initial pipe to start a table, and then
tabs/return/letters to create the rest. Combined with elastic
tabstops, I've never seen an easier way to create MMD or PHP
Markdown Extra tables that look great in the source as well.</p>
<p>F-</p>
<h2><a href="#" class="anchor" name=""></a></h2>
<p>Fletcher T. Penney<br>
<a href=
"mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a></p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-16T08:53:52Z2013-06-16T08:53:52ZExtended Table Syntax<div><p>I think i was testing a table that didn't have tabs in it
already.<br>
Therefore, pointing the cursor just before the pipe and then
pressing<br>
tab resulted in the "weird" behaviour of creating an additional
pipe. Of<br>
course, it's sufficiently easy to delete these extra pipes.</p>
<p>With "badly scrambled" i meant that with the soft wrap the lines
aren't<br>
clear anymore when the source panel is too small or the table is
too<br>
large. I think you should either mark the wrapped lines in a
different<br>
style or symbol (like many text editors do). Alternatively, you
could<br>
highlight the colomn you are just in for the whole table: i.e. if
the<br>
cursor is in the 3rd cell of one row, then also each 3rd cell of
the<br>
other rows will get highlighted.</p>
<p>I really love elastic tabstops, but i feel they are not
sufficiently<br>
spread throughout different text editing software. I would
therefore<br>
suggest to (optionally) save the "elastic tabstops" with blanks
before<br>
them to make them easily readable in other editors (with
mono-spaced<br>
font) too. Sublime text has a plugin that does exactly that,
because<br>
there was no way of integrating real elastic tabstops.</p>
<p>some_text--->elastic<br>
more.....--->stuff</p>
<p>jakov</p></div>Jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-16T12:33:43Z2013-06-16T12:33:43ZExtended Table Syntax<div><p>Jakov,</p>
<p>Yes. If you have lines that are longer than the width of your
window, they will soft wrap. There is nothing I can do about this
--- in Composer v1 I experimented with not wrapping lines inside
tables, which caused all sorts of strange behavior and wasn't worth
it. You can always buy additional monitors and have the document
window spread across 3 displays, which should allow you to have
pretty wide tables that are all perfectly aligned. ;) Or you can
shrink the font down to 6 pt and use a magnifying glass....</p>
<p>Again, there are limits to the expression of arbitrarily
complex/wide tables in a plain text format, particularly when you
are limiting the width of the tables.</p>
<p>Elastic tabstops are a ridiculously elegant solution to a big
problem. I don't understand why more editors aren't using them.
There is a script that can be used to clean up MMD tables for
viewing in "dumb" text editors in a monospace font:</p>
<pre>
<code>https://github.com/fletcher/MMD-Support/blob/master/Utilities/table_cleanup.pl</code>
</pre>
<p>But elastic tabstops are a much better solution.</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-18T20:27:05Z2013-06-18T20:27:05ZExtended Table Syntax<div><p>Latest push to github supports '=====' for designating a table
column as a header.</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-20T21:09:38Z2013-06-20T21:09:38ZExtended Table Syntax<div><p>Cool! :)</p>
<p>Thinking in this direction i d like to ask if there is a way for
setting table footers (as in html)? I know your syntax if a single
blank row for additional bodies. Is the last body always the
footer?</p>
<p>If not so, i would suggest using the dashes row again like
this:</p>
<table>
<tr>
<th>Head</th>
<th>head</th>
</tr>
<tr>
<td>Body</td>
<td>body</td>
</tr>
<tr>
<td>---------</td>
<td>---------</td>
</tr>
<tr>
<td>Footer</td>
<td>footer</td>
</tr>
</table>
<p>Alternatively, underlines fir the footer:</p>
<table>
<tr>
<th>Head</th>
<th>head</th>
</tr>
<tr>
<td>Body</td>
<td>body</td>
</tr>
<tr>
<td>_______</td>
<td>______</td>
</tr>
<tr>
<td>footer</td>
<td>footer</td>
</tr>
</table>
<p>Am 18.06.2013 um 22:27 schrieb "fletcher" <a href=
"mailto:tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com">
tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com</a>:</p></div>Jakobtag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-06-21T17:19:02Z2013-06-21T17:19:02ZExtended Table Syntax<div><p>There is not currently a footer feature for tables.</p>
<p>I'll consider this for the future.</p>
<p>F-</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-10-09T14:17:38Z2013-10-09T14:17:38ZExtended Table Syntax<div><p>So, is there such a thing as a cell spanning multiple rows in
MultiMarkdown at this time?</p></div>KStag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-10-09T14:19:01Z2013-10-09T14:19:01ZExtended Table Syntax<div><p>No. Just multiple columns. I have yet to see a suitable proposal
for a syntax for cells spanning multiple rows.</p>
<p>F-</p>
<h2><a name="" href="#" class="anchor"></a></h2>
<p>Fletcher T. Penney<br>
<a href=
"mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a></p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-10-09T15:15:53Z2013-10-09T15:15:56ZExtended Table Syntax<div><p>Thanks Fletcher. Is the issue just syntax, or use cases?</p></div>KStag:support.fletcherpenney.net,2013-02-12:Comment/272129602013-10-09T15:46:07Z2013-10-09T15:46:07ZExtended Table Syntax<div><p>Syntax. I haven't seen anything that is suitably:</p>
<p>1) Simple to write with a "dumb" text editor<br>
2) Easy to read if you're not familiar with the syntax<br>
3) Looks natural, and not too much like computer markup<br>
4) Reasonably easy to parse</p>
<p>F-</p>
<h2><a name="" href="#" class="anchor"></a></h2>
<p>Fletcher T. Penney<br>
<a href=
"mailto:fletcher@fletcherpenney.net">fletcher@fletcherpenney.net</a></p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-06-24T14:47:51Z2014-06-24T14:47:54ZExtended Table Syntax<div><p>Hi Fletcher,</p>
<p>I really appreciate your work in Multimarkdown which really
helpful with its "Multi Features".</p>
<p>For the lack of 'row span' feature, I don't see anyone has
mention to the table syntax of TexTile (<a href=
"http://redcloth.org/textile/page-layout/#tables">http://redcloth.org/textile/page-layout/#tables</a>)</p>
<p>Textile<br>
|{background:#ddd}. Cell with background|Normal| |\2. Cell spanning
2 columns| |/2. Cell spanning 2 rows|one| |two| |>.
Right-aligned cell|<. Left-aligned cell|</p>
<p>Why don't we use the number instead of the number of symbol for
cell spanning issue?</p>
<p>Thanks,<br>
Tu</p></div>duongtutag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-06-25T18:43:49Z2014-06-25T18:43:49ZExtended Table Syntax<div><p>That looks even less like something I would type in an email to
a friend to represent a table.</p>
<p>F-</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-11-14T15:32:38Z2014-11-14T15:32:38ZExtended Table Syntax<div><p>What about just using "^"?<br>
For example,</p>
<p>| | Divisible | Indivisible |<br>
| - | :------------------: | :-------------------------------:
|<br>
| A | initial + subsequent | jointly & severally for entire
harm |<br>
| B | subsequent | ^ |<br>
[Proximate Subsequent Act Liability Chart]</p></div>Juliántag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-11-17T19:17:16Z2014-11-17T19:17:16ZExtended Table Syntax<div><p>When I see, that I think that the intent is to repeat the above
line (like a "same here").</p></div>fletchertag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-11-17T20:37:27Z2014-11-17T20:37:28ZExtended Table Syntax<div><p>Spanning cells <em>are</em> a way of saying "same here" most of
the times, aren't they?</p>
<p>If one would like to repeat the content of the cell above, one
could easily use copy and paste, or use a different syntax: I would
suggest {...}, but I doubt that it is necessary.</p>
<p>Jakov</p>
<p>On 17. November 2014 20:17:18 MEZ, fletcher <a href=
"mailto:tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com">
tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com</a>
wrote:</p></div>jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-11-17T23:06:33Z2014-11-17T23:06:34ZExtended Table Syntax<div><p>That's a legitimate interpretation of that notation. For my
charts, when<br>
it's important to have duplicate text in multiple cells, I'll
definitely<br>
copy and paste. When it's important that two cells lead to the
same<br>
cell/conclusion, I'll use ^ to mean that it's a continuation of the
meaning<br>
above. I guess how important the distinction is depends on whether
one<br>
thinks there's a difference between cells that say the same thing
and a<br>
vertical cell that spans more than one row.</p>
<p>Cheers,<br>
Julián<br>
On 2014-11-17 3:37 PM, "jakov" < <a href=
"mailto:tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com">
tender2+dc9ed6d6da28a140edeb2ab439f21d76b115ee490@tenderapp.com</a>>
wrote:</p></div>gomezbiagitag:support.fletcherpenney.net,2013-02-12:Comment/272129602014-11-18T18:13:22Z2014-11-18T18:13:22ZExtended Table Syntax<div><p>+1. I just wanted to point out that it's just a small
difference, not something that would result in entirely unexpected
results.</p>
<p>The only difficulty is how to handle combinations of rowspan and
colspan. In my opinion colspan would get defined in the first line
as "| ... ||" and in the second line the number of trailing bars in
"| ^ |||" would not change anything.</p></div>jakovtag:support.fletcherpenney.net,2013-02-12:Comment/272129602016-05-23T13:45:34Z2016-05-23T13:45:35ZExtended Table Syntax<div><p>Magnificent job! Merrilee</p></div>WilliamUsettag:support.fletcherpenney.net,2013-02-12:Comment/272129602016-06-07T22:43:42Z2016-06-07T22:43:43ZExtended Table Syntax<div><p>Thanks for sharing, this is a fantastic forum.Really looking
forward to read more. Keep writing. Buess</p></div>WilliamUset