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
