Markdown development

[yy]

2010/3/24  <Bowerbird at aol.com>:

> but, you know, all it takes is for one brave leader to _lead_,

> and a number of non-cowardly followers to _follow_, and

> -- before you know it -- a new capability is taken for granted.


Elastic tab stops are not a new concept. Some people tried to lead,
nobody followed.


>>   It also means that MD needs to recognize

>>   at least two ways to do tables -- ets and markup.

>

> well, if you want to keep a horse around in addition to

> your new horseless carriage, by all means, feel free...         ;+)


As long as there are no roads for the horseless carriage I think is a
good idea. YMMV.


>>   Are you saying that browsers should all be smart enough

>>   to recognize elastic tab stops?

>

> yes.  every text-editing environment should have the capability.

>

> because -- if you've programmed it, like i have -- you'll know

> that it's really not all that difficult to code.  indeed, it's easy...


I have programmed them to, because I loved the concept, but it was not
so easy. It complicates the code, very much. It is not difficult, but
it gives very ugly results.

When I'm rendering text I don't want to have to scan the whole file
just to adjust tab stops, as sometimes happen. In fact, I prefer not
having to look ahead at all.


> and although i don't remember this in the work-up on them

> (because i conceived them long before that, independently),

> this functionality should include a feature that will convert

> multiple spaces to a tab character (the easy part) as well as

> convert a tab to the "correct" number of multiple spaces...

> (e.g., so the table displays correctly in a monospaced font).

> i'd think the default save-format would be multiple-spaces,

> just to accommodate the non-tab-aware software out there.


This is not a final solution. The main reason I implemented ets was to
use variable width fonts, and those ones do not play well with the
spaces-tab conversion.


> there's nothing "magical" about this functionality.  it's just

> a straightforward implementation of old-fashioned tabs,

> with the new wrinkle that the columns are self-adjusting

> to the size they need to be.  which is something we could

> have reasonably expected our computers to do all along...


How do you represent tabs in the output of a tool like sed, for
example? It is not such an easy problem, really.


> (indeed, isn't this capability already in most spreadsheets?)


afaik, no. Spreadsheets used fixed width columns last time I checked.
This width can be adjusted, but it is not "elastic".


> but in cost-benefit terms, cost being low, benefits being high,

> this particular feature is one that has a good cost-benefit ratio.

>

> all it will take is for somebody out front to "just do it"...


... and the others to follow. Don't forget that part, because it could
be the most difficult one.


> this is _not_ a betamax/vhs situation.  vhs was "good enough".

> nobody says our current table functionality is "good enough".


Tables are a complex problem. I don't think elastic tab stops will
change that. Somebody could arguee that the fact that everybody is
still using the classical tab stops make them good enough. Again,
YMMV.

-- 
- yiyus || JGL . 4l77.com