Re: Markdown development

[Seumas Mac Uilleachan]

On 25/03/10 10:08 AM, Aristotle Pagaltzis wrote:

* Seumas Mac Uilleachan  [2010-03-24 01:30]:
   

Elastic tabstops would certainly make my pseudo-table much
cleaner. Would make creating such a table a breeze without
requiring special markup. Is this idea actually catching on
 

Yeah, elastic tabstops solve this problem in a fundamental way.
The problem is they’re a boil-the-ocean solution, they require
support in almost all tools that will touch the document in
question. That’s a very high activation energy barrier… you’ll
need a catalyst to get them adopted, eg. a new OS/platform that
fully supports them from the get-go – essentially you need an
Apple to throw their weight behind it.

   

like Sony Beta - a better solution that no one will buy into?
 

Myth. Betamax was inferior to VHS in significant ways, even if
it had an obvious advantage in picture quality and cassette size.
The market decided that people prefer VHS’ mix of good and bad to
Betamax’ mix of good and bad. End of story.

It’s like saying webmail is inferior to desktop mail clients.

Regards,
   
Beta was inferior to VHS in market penetration because VHS was licensed 
for free and Beta wasn't. Much like the PC vs Mac early on. In both 
cases the Beta and Mac were technologically superior but cost more.

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

Re: Markdown development

[Aristotle Pagaltzis]

* Seumas Mac Uilleachan  [2010-03-24 01:30]:
> Elastic tabstops would certainly make my pseudo-table much
> cleaner. Would make creating such a table a breeze without
> requiring special markup. Is this idea actually catching on

Yeah, elastic tabstops solve this problem in a fundamental way.
The problem is they’re a boil-the-ocean solution, they require
support in almost all tools that will touch the document in
question. That’s a very high activation energy barrier… you’ll
need a catalyst to get them adopted, eg. a new OS/platform that
fully supports them from the get-go – essentially you need an
Apple to throw their weight behind it.

> like Sony Beta - a better solution that no one will buy into?

Myth. Betamax was inferior to VHS in significant ways, even if
it had an obvious advantage in picture quality and cassette size.
The market decided that people prefer VHS’ mix of good and bad to
Betamax’ mix of good and bad. End of story.

It’s like saying webmail is inferior to desktop mail clients.

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

re: Markdown development

[Bowerbird]

sherwood said:
>The bowerbird is half right.  
>Elastic tab stops are worthy of implementing.
>But to keep the transition cost minimal 
>the older way has to be supported also.

well, no, actually, i'm _completely_ right...
since i never said to jettison the older way.  :+)
(which is why david's comment makes no sense.)

we could certainly say that "markdown supports
elastic tabs" and leave it to the various coders to
decide for themselves whether _they_ support it.

although even after everyone fully implements
elastic tabs, we can still support "the older way".
horses are fun to ride sometimes...

***

seumas said:
>   You're not really talking tables here though, 
>you're talking self-aligning columns of text. 
>That is not the same thing as an html table, 
>even though that is what tables are often used for.

we start with self-aligning columns of text, yes.
but it's certainly possible to extend from there...

of course you can probably sketch out some table
that would be impossible for us to handle nicely,
in which case we'd have to back off and use .html.

but -- as far as i can see, do tell me if i'm wrong --
that's the suggestion for what we should always do,
which i do not find to be a compelling alternative...

***


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

yet we are still talking about how to do tables...


>   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.

i can handle "not so easy" as long as it's "not difficult". ;+)
as for giving ugly results, that's not true of _my_ code.


>When I'm rendering text I don't want to have to 
>scan the whole file just to adjust tab stops, 
>as sometimes happen. 

i treat every table independently, so i only have to
scan through to the end of the table to set the tabs.


>In fact, I prefer not having to look ahead at all.

well, gee, i read the whole file in advance anyway,
because it's impossible to do all the things i want
without knowing what the entire file looks like...

my first page must know the last page, intimately.


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

monospaced spaces and proportional fonts
cannot work well, by definition, i'm afraid...


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

sed needs to be programmed to do that, is all...


>Spreadsheets used fixed width columns 
>last time I checked.

i do believe that spreadsheets can self-adjust.
and i'm almost certain that ms-word-tables can.

although i am loathe to ever start up ms-word,
i'll do so if you tell me you need me to verify it.


>Somebody could arguee that 
>the fact that everybody is still using 
>the classical tab stops make them good enough.

i'd love to hear someone argue that.   i'd chuckle.   :+)

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

Re: Markdown development

[Seumas Mac Uilleachan]

On 24/03/10 02:20 PM, Sherwood Botsford wrote:
Given the paucity of ETS editors, viewers, enabled browsers  however, 
I'm afraid that I will insist on keeping my horse, at least until 
there is more than two roads in town.  My horse will eat hay.  And who 
knows where the next gas station is.


The bowerbird is half right.  Elastic tab stops are worthy of 
implementing.  But to keep the transition cost minimal the older way 
has to be supported also.


I can see merit in having MD understand elastic tab stops as part of 
it's goal toward minimalist markup.

It certainly would make simple tables easy to do.



Respectfully,

Sherwood of Sherwood's Forests

Sherwood Botsford
Sherwood's Forests -- http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0




If I understand the concept correctly, Markdown wouldn't really have to 
know anything about ets. Their implementation would be up to the 
browser-editor-ide-etc. All MD would have to worry about is tabs. If 
there's a tab in the middle of three lines of text, adjust the text 
after each tab to line up. If there's a tab in front of three lines of 
text line up the three lines. If there's two tabs, indent it more. The 
actual lining up is not MD's problem. Currently MD has the tab at the 
beginning of the line stuff. A tab in the middle of a line shouldn't 
affect MD at all, should it?


The actual implementation would depend on whether the font was 
monospaced or proportional, again something MD doesn't care about.





On Wed, Mar 24, 2010 at 12:11 PM, david parsons > wrote:


In article <1ffdc.6466484d.38dba...@aol.com
>,
mailto:markdown-discuss@six.pairlist.net>> wrote:
>
>--===1294852797==
>Content-Type: multipart/alternative;
>   boundary="part1_1ffdc.6466484d.38dbaac4_boundary"
>
>
>--part1_1ffdc.6466484d.38dbaac4_boundary
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>
>sherwood said:
>>I don't understand.
>
>what's to understand?   :+)
>
>
>>Are you saying that MD should recognize elastic tab stops
>>in a file and convert that to a html table?
>
>yes, that's what i'm saying, or at least part of it.

   And this would convert markdown from a general-purpose writers tool
   into some sort of boutique plugin.   I can't really see that this
   would count as an advantage to _anyone_ who currently uses
markdown.

   -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
   


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

Re: Markdown development

[Seumas Mac Uilleachan]

On 24/03/10 01:49 PM, bowerb...@aol.com wrote:

sherwood said:
>   I don't understand.

what's to understand?  :+)


>   Are you saying that MD should recognize elastic tab stops
>   in a file and convert that to a html table?

yes, that's what i'm saying, or at least part of it.


>   This is certainly a possible route, but given
>   the number of editors that don't recognize
>   elastic tab stops, this is daunting.

at some point, you have to free yourself from the constraints
that low-quality software imposes on your workflow, yes sir...

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.


>   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... ;+)


>   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...

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.

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...
(indeed, isn't this capability already in most spreadsheets?)


>   While an admirable goal, I won't hold my breath for the day
>   that 95% of browsing is done with ETS capable browsers.

i'm not holding my breath for 95% of browsers being _capable_,
in _any_ sense of the word, not as long as we have a microsoft...

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"...

this is _not_ a betamax/vhs situation.  vhs was "good enough".
nobody says our current table functionality is "good enough".

-bowerbird



You're not really talking tables here though, you're talking 
self-aligning columns of text. That is not the same thing as an html 
table, even though that is what tables are often used for.



___
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: Markdown development

[Sherwood Botsford]

Given the paucity of ETS editors, viewers, enabled browsers  however, I'm
afraid that I will insist on keeping my horse, at least until there is more
than two roads in town.  My horse will eat hay.  And who knows where the
next gas station is.

The bowerbird is half right.  Elastic tab stops are worthy of implementing.
But to keep the transition cost minimal the older way has to be supported
also.

I can see merit in having MD understand elastic tab stops as part of it's
goal toward minimalist markup.
It certainly would make simple tables easy to do.



Respectfully,

Sherwood of Sherwood's Forests

Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0




On Wed, Mar 24, 2010 at 12:11 PM, david parsons  wrote:

> In article <1ffdc.6466484d.38dba...@aol.com>,
>   wrote:
> >
> >--===1294852797==
> >Content-Type: multipart/alternative;
> >   boundary="part1_1ffdc.6466484d.38dbaac4_boundary"
> >
> >
> >--part1_1ffdc.6466484d.38dbaac4_boundary
> >Content-Type: text/plain; charset="US-ASCII"
> >Content-Transfer-Encoding: 7bit
> >
> >sherwood said:
> >>I don't understand.
> >
> >what's to understand?   :+)
> >
> >
> >>Are you saying that MD should recognize elastic tab stops
> >>in a file and convert that to a html table?
> >
> >yes, that's what i'm saying, or at least part of it.
>
> And this would convert markdown from a general-purpose writers tool
>into some sort of boutique plugin.   I can't really see that this
>would count as an advantage to _anyone_ who currently uses markdown.
>
>-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: Markdown development

[yy]

2010/3/24  :
> 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
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[david parsons]

In article <1ffdc.6466484d.38dba...@aol.com>,
  wrote:
>
>--===1294852797==
>Content-Type: multipart/alternative;
>   boundary="part1_1ffdc.6466484d.38dbaac4_boundary"
>
>
>--part1_1ffdc.6466484d.38dbaac4_boundary
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>
>sherwood said:
>>I don't understand.
>
>what's to understand?   :+)
>
>
>>Are you saying that MD should recognize elastic tab stops
>>in a file and convert that to a html table?
>
>yes, that's what i'm saying, or at least part of it.

And this would convert markdown from a general-purpose writers tool
into some sort of boutique plugin.   I can't really see that this
would count as an advantage to _anyone_ who currently uses markdown.

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

re: Markdown development

[Bowerbird]

sherwood said:
>I don't understand.

what's to understand?   :+)


>Are you saying that MD should recognize elastic tab stops
>in a file and convert that to a html table?

yes, that's what i'm saying, or at least part of it.


>This is certainly a possible route, but given 
>the number of editors that don't recognize 
>elastic tab stops, this is daunting.

at some point, you have to free yourself from the constraints
that low-quality software imposes on your workflow, yes sir...

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.


>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...  ;+)


>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...

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.

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...
(indeed, isn't this capability already in most spreadsheets?)


>While an admirable goal, I won't hold my breath for the day 
>that 95% of browsing is done with ETS capable browsers.

i'm not holding my breath for 95% of browsers being _capable_,
in _any_ sense of the word, not as long as we have a microsoft...

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"...

this is _not_ a betamax/vhs situation.   vhs was "good enough".
nobody says our current table functionality is "good enough".

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

Re: Markdown development

[David E. Wheeler]

On Mar 23, 2010, at 8:29 PM, Seumas Mac Uilleachan wrote:

> Elastic tabstops would certainly make my pseudo-table much cleaner. Would 
> make creating such a table a breeze without requiring special markup. Is this 
> idea actually catching on or is it like Sony Beta - a better solution that no 
> one will buy into?

My sense is the latter.

Best,

David

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

Re: Markdown development

[Seumas Mac Uilleachan]

On 23/03/10 02:11 AM, Albert Skye wrote:

It depends on what you are trying to do. If you want a simple
multi-column list of corresponding text such as:

Position  Team  P  GD  PTS
1 Man Utd 31 46  67
2 Arsenal  31 40   67
3 Chelsea  29 42  64
4 Tottenham 30 26  55
5 Liverpool   31 19   52
6 Man City28 17   50
7 Aston Villa 29 17   50
8 Everton  30  6   45
9 Birmingham   30 -3   44
10   Fulham   29  0   38
11   Stoke  30 -6   36
12   Sunderland30 -6   34
13   Blackburn  29 -17 34
14   Bolton 31 -20 32
15   Wigan 31 -30 31
16   Wolves30 -24 28
17   West Ham   30 -14 27
18   Burnley   31 -33 24
19   Hull 30 -35 24
20   Portsmouth30 -25 13

 

FWIW, that's pretty illegible at whatever tab width my MUA uses.

Best,

David

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


   

FWIW it isn't an html-formatted table. I just copied it from a
football website. It doesn't look very nice in mine either. The
spacings got all messed up in copying but I wasn't going to take the
time to fix it.
 

It's certainly legible in Georgia.

   

And another problem is fixed vs variable fonts. I tend to use a
variable font in my MUA (and elsewhere). That makes aligning text
with tabs virtually impossible.
 

Eventually, the character column will no longer be taken for granted. The 
sooner the better, for me. Syntax for tables (and anything else) which depends 
on fixed-width font formatting seems innately brittle and shorter of life than 
syntax which does not have that dependency.

Elastic tabstops.
http://nickgravgaard.com/elastictabstops/
   


Elastic tabstops would certainly make my pseudo-table much cleaner. 
Would make creating such a table a breeze without requiring special 
markup. Is this idea actually catching on or is it like Sony Beta - a 
better solution that no one will buy into?

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

Re: Markdown development

[Sherwood Botsford]

On Tue, Mar 23, 2010 at 12:44 PM,  wrote:

> albert said:
> >   http://nickgravgaard.com/elastictabstops/
>
> for the win!  (i'd been wondering when someone would
> mention that again; i looked and couldn't find the u.r.l.)
>
> any further dialogs about tables should be shortcircuited
> with this link.  there's simply nothing to discuss any more.
>
> -bowerbird
>
>
>
I don't understand.

Are you saying that MD should recognize elastic tab stops in a file and
convert that to a html table?

This is certainly a possible route, but given the number of editors that
don't recognize elastic tab stops, this is daunting.  It also means that MD
needs to recognize at least two ways to do tables -- ets and markup.

Are you saying that browsers should all be smart enough to recognize elastic
tab stops?

While an admirable goal, I won't hold my breath for the day that 95% of
browsing is done with ETS capable browsers.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Markdown development

[Bowerbird]

albert said:
>http://nickgravgaard.com/elastictabstops/

for the win!   (i'd been wondering when someone would
mention that again; i looked and couldn't find the u.r.l.)

any further dialogs about tables should be shortcircuited
with this link.   there's simply nothing to discuss any more.

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

re: Markdown development

[Bowerbird]

lou said:
>And, again, it's always been part of the bargain that 
>you must wrap the transformer if you need special shit

where some values of "special shit" are spectacularly ordinary...

not available in stores.   your mileage might vary.   have a nice day.

-bowerbird

p.s.   see what gruber does on his blog.   capability-wise, it's bland.
the most "special" he does is footnotes, and he hand-rolls those.

p.p.s.   but honestly, it's really not what markdown out-of-the-box
_fails_ to do automatically.   it's how much work it takes for you to
do those things manually.   at some point, for any "special shit",
you will feel like you've done so much markup anyway that you
might as well have just done it _all_ in .html from the beginning.
that is, as "light" markup, markdown simply isn't "light" enough.
i do not necessarily mean for this to sound like a criticism, but
in my work, i've been aiming at something much, much lighter.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Albert Skye]

>>> It depends on what you are trying to do. If you want a simple 
>>> multi-column list of corresponding text such as:
>>> 
>>> Position  Team  P  GD  PTS
>>> 1 Man Utd 31 46  67
>>> 2 Arsenal  31 40   67
>>> 3 Chelsea  29 42  64
>>> 4 Tottenham 30 26  55
>>> 5 Liverpool   31 19   52
>>> 6 Man City28 17   50
>>> 7 Aston Villa 29 17   50
>>> 8 Everton  30  6   45
>>> 9 Birmingham   30 -3   44
>>> 10   Fulham   29  0   38
>>> 11   Stoke  30 -6   36
>>> 12   Sunderland30 -6   34
>>> 13   Blackburn  29 -17 34
>>> 14   Bolton 31 -20 32
>>> 15   Wigan 31 -30 31
>>> 16   Wolves30 -24 28
>>> 17   West Ham   30 -14 27
>>> 18   Burnley   31 -33 24
>>> 19   Hull 30 -35 24
>>> 20   Portsmouth30 -25 13
>>>  
>> FWIW, that's pretty illegible at whatever tab width my MUA uses.
>> 
>> Best,
>> 
>> David
>> 
>> ___
>> Markdown-Discuss mailing list
>> Markdown-Discuss@six.pairlist.net
>> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>> 
>>
> FWIW it isn't an html-formatted table. I just copied it from a 
> football website. It doesn't look very nice in mine either. The 
> spacings got all messed up in copying but I wasn't going to take the 
> time to fix it.

It's certainly legible in Georgia.

> And another problem is fixed vs variable fonts. I tend to use a 
> variable font in my MUA (and elsewhere). That makes aligning text 
> with tabs virtually impossible.

Eventually, the character column will no longer be taken for granted. The 
sooner the better, for me. Syntax for tables (and anything else) which depends 
on fixed-width font formatting seems innately brittle and shorter of life than 
syntax which does not have that dependency.

Elastic tabstops.
http://nickgravgaard.com/elastictabstops/
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Lou Quillio]

>> Markdown's dead? Absurd.
>
> Obviously. That’s why no one said that.
>
> Markdown *development* is dead.
>
> (Straw men are easy to clobber.)

And cherries are easy to pick.  My point is that the canonical
ambitions that some have for Markdown aren't shared by it's author
(Gruber) and it's adoptive parent (Michel Fortin).  I'd argue that
this is an acceptable state of affairs, especially considering the
wild success of the general format and the appearance of gentlemen
like Thomas Leitner and his kramdown project.  To me, this is a line
of maintainers, each picking up the tacit core, which is 96% finished
by now.  And, again, it's always been part of the bargain that you
must wrap the transformer if you need special shit, or if you
regularly work with an unresolved edge case.

I think that elevating Markdown to a grammar and taking an obligation
to produce and maintain coordinated transformers in multiple languages
is a nice ambition for somebody to have.  I doubt very much that it
would deliver benefits over the status quo that would justify the
effort.  I could be wrong.

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

Re: Markdown development

[Seumas Mac Uilleachan]

On 21/03/10 08:28 PM, David E. Wheeler wrote:

On Mar 21, 2010, at 11:03 AM, Seumas Mac Uilleachan wrote:

   

It depends on what you are trying to do. If you want a simple multi-column list 
of corresponding text such as:

Position  Team  P  GD  PTS
1 Man Utd 31 46  67
2 Arsenal  31 40   67
3 Chelsea  29 42  64
4 Tottenham 30 26  55
5 Liverpool   31 19   52
6 Man City28 17   50
7 Aston Villa 29 17   50
8 Everton  30  6   45
9 Birmingham   30 -3   44
10   Fulham   29  0   38
11   Stoke  30 -6   36
12   Sunderland30 -6   34
13   Blackburn  29 -17 34
14   Bolton 31 -20 32
15   Wigan 31 -30 31
16   Wolves30 -24 28
17   West Ham   30 -14 27
18   Burnley   31 -33 24
19   Hull 30 -35 24
20   Portsmouth30 -25 13
 

FWIW, that's pretty illegible at whatever tab width my MUA uses.

Best,

David

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

   
FWIW it isn't an html-formatted table. I just copied it from a football 
website. It doesn't look very nice in mine either. The spacings got all 
messed up in copying but I wasn't going to take the time to fix it.


The point was that this is a commonly-used table type that there should 
be some standard mechanism for Markdown to deal with (and make it 
legible). There is such a mechanism in PHP Markdown Extra. There is in 
Multimarkdown (similar but different). There probably are in others as 
well (again similar but different). In vanilla Markdown there's html. 
Html as plain text is pretty illegible, much more so than this quick 
mashup table above.


And another problem is fixed vs variable fonts. I tend to use a variable 
font in my MUA (and elsewhere). That makes aligning text with tabs 
virtually impossible.

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

Re: Markdown development

[David E. Wheeler]

On Mar 21, 2010, at 11:03 AM, Seumas Mac Uilleachan wrote:

> It depends on what you are trying to do. If you want a simple multi-column 
> list of corresponding text such as:
> 
> Position  Team  P  GD  PTS
> 1 Man Utd 31 46  67
> 2 Arsenal  31 40   67
> 3 Chelsea  29 42  64
> 4 Tottenham 30 26  55
> 5 Liverpool   31 19   52
> 6 Man City28 17   50
> 7 Aston Villa 29 17   50
> 8 Everton  30  6   45
> 9 Birmingham   30 -3   44
> 10   Fulham   29  0   38
> 11   Stoke  30 -6   36
> 12   Sunderland30 -6   34
> 13   Blackburn  29 -17 34
> 14   Bolton 31 -20 32
> 15   Wigan 31 -30 31
> 16   Wolves30 -24 28
> 17   West Ham   30 -14 27
> 18   Burnley   31 -33 24
> 19   Hull 30 -35 24
> 20   Portsmouth30 -25 13

FWIW, that's pretty illegible at whatever tab width my MUA uses.

Best,

David

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

Re: Markdown development

[David E. Wheeler]

On Mar 21, 2010, at 6:13 AM, Aristotle Pagaltzis wrote:

> They look OK but are a pain to edit. (I haven’t seen a table
> syntax that I find easier to edit than raw HTML. Well, the fact
> that Markdown won’t touch the contents makes them still a pain.)
> 
> I think this editing|reading tension is fundamental, therefor not
> resolvable.

Well, I didn't have that issue with the definition lists (the formatting is 
not, after all, all that different from unordered lists), but agree with you on 
tables. I likely would load data into PostgreSQL and let psql format things for 
me for all but the simplest tables. But at least I'd have that tool.

The advantage over HTML is of course plain if you want them to be legible as 
plain text.

> I wouldn’t want any configurable behaviours, though. To me it is
> a very important point that you can take a Markdown document from
> one environment to another without breakage.

+1

> In case you are referring to my own recent mail, I never said it
> needs *Gruber*’s blessing specifically. What it does need is one
> central voice. If you think it doesn’t, then ask yourself why all
> of the reimplementations have added their own features, yet none
> of them have copied each other.

There doesn't need to be one voice, but one spec would definitely be valuable. 
There can be community consensus building toward developing that spec, but a 
dictator is hardly necessary.

> But that’s the point. To get more than Just Another Fork, it neds
> to have weight of voice to bring all the other forks together
> behind it.

Or the consensus of those on this list, especially if Gruber were to formally 
resign.

> The problem with tables as I see it is as above: I think that
> tables fundamentally cannot be both easy to edit and easy to read
> within the constraints of plaintext.

No, but one can use tools to format them when necessary.

Best,

David

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

Re: Markdown development

[Albert Skye]

> What it does need is one central voice.

That's one way to do it, and as unlikely as it may seem, cooperation is another 
way. In that case, a will to cooperate is necessary.

In any case, it seems useful to at least clean up and disambiguate a common 
Markdown core. I think Markdown would be more useful were it (and this 
community) more coherent. If that means the installation of a new sovereign, so 
be it.

Anyway, my own interest favours the more general problem of an unambiguous 
syntax for structured text (rather than an alternative representation for HTML) 
and I certainly don't expect Markdown to address that, though I imagine others 
reading this list share similar interest.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Sherwood Botsford]

>
> Position  Team  P  GD  PTS
> 1 Man Utd 31 46  67
> 2 Arsenal  31 40   67
> 3 Chelsea  29 42  64
> 4 Tottenham 30 26  55
> 5 Liverpool   31 19   52
> 6 Man City28 17   50
> 7 Aston Villa 29 17   50
> 8 Everton  30  6   45
> 9 Birmingham   30 -3   44
> 10   Fulham   29  0   38
> 11   Stoke  30 -6   36
> 12   Sunderland30 -6   34
> 13   Blackburn  29 -17 34
> 14   Bolton 31 -20 32
> 15   Wigan 31 -30 31
> 16   Wolves30 -24 28
> 17   West Ham   30 -14 27
> 18   Burnley   31 -33 24
> 19   Hull 30 -35 24
> 20   Portsmouth30 -25 13
>
> It should be possible to do without having to use html. For more complex
> tables (eg multiple lines in spanning cells, tables within tables) you are
> getting into a different kettle of fish - I can see requiring html for that.
>



 Agreed.  This is the sort of thing that I do right now with MMD's tables.
Doing nested tables in HTML by hand is awful.  My response to nested tables
is "Please don't"  I know some layout mavins  use this to control
presentation.  I prefer  + CSS.  I often use this construct to add
illustration to an article  and 

A colleague of mine used tabs for programming indents, and commented that
once the indents got the the point where there wasn't enough line left to
work, it was time to abstract.  Pull a chunk out as a subroutine or
function.

HTML generally, and in tables in particular, can have too many open tags.
In general I find that not being able to see the close on the same page as
the open makes for error prone writing.
Unfortunately there is no good way in html to do the equivalent of a
subroutine, to abstract it out. We have a plethora of CMS systems to enable
us to try to keep the content separate from the presentation, so that we
have to do the difficult stuff less often.

MD is a device for enabling the content to be less cluttered.  It's not full
separationg from presentation, but it's good enough.

Different people have different itches.  And so MD forks in a multitude of
ways.

If someone wants order they have to *want* it enough to put a fair amount of
work on it.

They would have to document the edge cases, badger each developer to fix the
bugs, and nudge toward concensus.  Possibly write dialect transform programs
to make moving stuff between one dialect and another.

One objection to configuration has been document portability.  Alas we don't
have that now because of the multiple forks.  Mind you adding configuration
could well make this problem worse, unless there is an umbrella organization
to use configurations to make forks more compatible instead of more
different.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Seumas Mac Uilleachan]

On 21/03/10 06:13 AM, Aristotle Pagaltzis wrote:

* Seumas Mac Uilleachan  [2010-03-21 00:45]:


I hear constantly about needing "Gruber's blessing" for any
overhaul or changes to Markdown. Why?
 

In case you are referring to my own recent mail, I never said it
needs *Gruber*’s blessing specifically. What it does need is one
central voice. If you think it doesn’t, then ask yourself why all
of the reimplementations have added their own features, yet none
of them have copied each other.
   


I wasn't referring to you specifically. I keep reading here about how 
the lack of input from him is what is causing the perceived 
fragmentation in Markdown implementations. All I meant to say is that 
Gruber seems to have lost interest in Markdown development and we just 
need to move beyond needing his blessing.



Except that several of them have copied Markdown Extra. As it
happens, Michel Fortin had some blessing from Gruber on several
of his efforts. Coincidence?

No one needs permission or blessing to fork Markdown. Many people
have done it.

But that’s the point. To get more than Just Another Fork, it neds
to have weight of voice to bring all the other forks together
behind it.

   

The goal of markdown is readability. There is no such thing as
a readable html table. I would argue that tables are a useful
enough feature to include. Whether it is done badly or well is
often subjective. At the minimum a simple table format would be
important to me (not requiring spanning cells or complex table
layouts). Tables are the easiest way to list corresponding
values or data that they really should be somehow included.
 

The problem with tables as I see it is as above: I think that
tables fundamentally cannot be both easy to edit and easy to read
within the constraints of plaintext.
   


It depends on what you are trying to do. If you want a simple 
multi-column list of corresponding text such as:


Position  Team  P  GD  PTS
1 Man Utd 31 46  67
2 Arsenal  31 40   67
3 Chelsea  29 42  64
4 Tottenham 30 26  55
5 Liverpool   31 19   52
6 Man City28 17   50
7 Aston Villa 29 17   50
8 Everton  30  6   45
9 Birmingham   30 -3   44
10   Fulham   29  0   38
11   Stoke  30 -6   36
12   Sunderland30 -6   34
13   Blackburn  29 -17 34
14   Bolton 31 -20 32
15   Wigan 31 -30 31
16   Wolves30 -24 28
17   West Ham   30 -14 27
18   Burnley   31 -33 24
19   Hull 30 -35 24
20   Portsmouth30 -25 13

It should be possible to do without having to use html. For more complex 
tables (eg multiple lines in spanning cells, tables within tables) you 
are getting into a different kettle of fish - I can see requiring html 
for that.

Regards,
   


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

Re: Markdown development

[Aristotle Pagaltzis]

* David E. Wheeler  [2010-03-20 23:05]:
> I'm pretty happy with MMD definition lists (with s/:/~/g)

I tried to like them.

> and with psql-style tables (mostly implemented in
> Markdent::Dialect::Theory. I find them both esthetically
> pleasing.

They look OK but are a pain to edit. (I haven’t seen a table
syntax that I find easier to edit than raw HTML. Well, the fact
that Markdown won’t touch the contents makes them still a pain.)

I think this editing|reading tension is fundamental, therefor not
resolvable.


* Sherwood Botsford  [2010-03-20 23:35]:
> G. K. Chesterton commented, "If something is worth doing, it's
> worth doing badly"

Only within limits.

> I like MMD's table syntax. Not perfect. Still a pain to
> construct, especially if you want to keep the notion of having
> to look reasonable as plain text.  But it *really* beats
> .

To look at? Beats it. To write? Not hardly.

Esp. if you leave off the closing tags, as I do these days when
I write tables in Markdown documents.

> At this point I can do it with template toolkit and include
> files, but it's more than a bit rube-goldbergish. In the league
> with programmable candle powered hydralic peanut butter
> spreaders.

Actually include files are how I would suggest you do that.
Better yet use a Markdown implementation where you can pass
a prepopulated table of link references (so that the Markdown
formatting won’t have to parse the same 1,400 link references
over and over).

> Easy way to modify the behaviour with certain tags.

One of the things I want is some way to make it easier to tell
Markdown to re-engage inside block tags, in a less klunky fashion
than Markdown Extra’s (I think?) markdown=1 pseudo-attribute.
I don’t have a good idea for this, though.

I wouldn’t want any configurable behaviours, though. To me it is
a very important point that you can take a Markdown document from
one environment to another without breakage.


* Seumas Mac Uilleachan  [2010-03-21 00:45]:
> I hear constantly about needing "Gruber's blessing" for any
> overhaul or changes to Markdown. Why?

In case you are referring to my own recent mail, I never said it
needs *Gruber*’s blessing specifically. What it does need is one
central voice. If you think it doesn’t, then ask yourself why all
of the reimplementations have added their own features, yet none
of them have copied each other.

Except that several of them have copied Markdown Extra. As it
happens, Michel Fortin had some blessing from Gruber on several
of his efforts. Coincidence?

No one needs permission or blessing to fork Markdown. Many people
have done it.

But that’s the point. To get more than Just Another Fork, it neds
to have weight of voice to bring all the other forks together
behind it.

> The goal of markdown is readability. There is no such thing as
> a readable html table. I would argue that tables are a useful
> enough feature to include. Whether it is done badly or well is
> often subjective. At the minimum a simple table format would be
> important to me (not requiring spanning cells or complex table
> layouts). Tables are the easiest way to list corresponding
> values or data that they really should be somehow included.

The problem with tables as I see it is as above: I think that
tables fundamentally cannot be both easy to edit and easy to read
within the constraints of plaintext.

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

Re: Markdown development

[Seumas Mac Uilleachan]

On 20/03/10 04:02 PM, Aristotle Pagaltzis wrote:

* Lou Quillio  [2010-03-20 00:55]:
   

Markdown's dead? Absurd.
 

Obviously. That’s why no one said that.

Markdown *development* is dead.

(Straw men are easy to clobber.)

   

Markdown's huge, and in the form of PHP Markdown Extra is
basically done. Done != dead, done == problem solved.
 

Fact: the latest Gruber release is a beta.
   
And has been for how many years now? The original markdown has not 
changed in years. That may be a good thing if it is stable, has no bugs 
or edge cases, does exactly what it advertises every time, etc etc.


But it does not, witness the constant threads on this mailing list about 
edge cases, missing features, etc etc.


Which leads me at least to presume that it is an orphaned software. It 
would certainly not be alone.


I hear constantly about needing "Gruber's blessing" for any overhaul or 
changes to Markdown. Why? It seems obvious to me that he has lost 
interest in further development. Markdown was developed to meet a 
requirement he had and I guess the current state is good enough for him. 
That is absolutely fine and I have no problem with that. If it isn't 
good enough for everyone else (or at least those who are active on this 
list) then carry on with development, call it MD2.0 or "Webtext Lite" or 
whatever you like and just run with it.

Fact: the latest official Gruber release is missing features
that Gruber himself uses.

You can argue about whether this means “done” – I see “scratches
my itch so I lost interest” –, but you cannot argue the facts.

Personally I think Markdown is still missing a lot of fit and
polish that could make it much (subtly) nicer still. (Eg. I’m
tired of using `` lines as a crutch to force consecutive,
separate blockquotes and lists to be recognised as such.)

What it’s not missing is big constructs. (I believe tables and
definition lists can only be done badly, and so should not be
done at all.)
   
The goal of markdown is readability. There is no such thing as a 
readable html table. I would argue that tables are a useful enough 
feature to include. Whether it is done badly or well is often 
subjective. At the minimum a simple table format would be important to 
me (not requiring spanning cells or complex table layouts). Tables are 
the easiest way to list corresponding values or data that they really 
should be somehow included.


I do like the way PHP Markdown Extra does tables. Unfortunately I don't 
use PHP anymore.

Regards,
   


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

Re: Markdown development

[Sherwood Botsford]

G. K. Chesterton commented, "If something is worth doing, it's worth doing
badly"

I like MMD's table syntax.  Not perfect.  Still a pain to construct,
especially if you want to keep the notion of having to look reasonable as
plain text.  But it *really* beats
.

My wishlist:

* Easy way to tell markdown to look in a file if it can't find link/image
references in the current file.  This would allow you to abstract a URL that
was referenced in several pages to a single ref.  In turn this makes changes
in the layout of a web site very easy.  At this point I can do it with
template toolkit and include files, but it's more than a bit
rube-goldbergish.  In the league with programmable candle powered hydralic
peanut butter spreaders.

* Easy way to modify the behaviour with certain tags.  According to the
spec, the contents of any HMTL tag are ignored.  Some dialects allow you to
put a flag in the tag to MD, but it has to be done for each use..  In
particular I want MD to *always* process the contents of  and generally
I think I want content processed more often than not even within an HTML
tag.  Fortunatley MMD considers upper case tags to be just text.  Which
means at present I'm dependent on the continued behaviour of a bug.


Respectfully,

Sherwood of Sherwood's Forests

Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[David E. Wheeler]

On Mar 20, 2010, at 4:02 PM, Aristotle Pagaltzis wrote:

> What it’s not missing is big constructs. (I believe tables and
> definition lists can only be done badly, and so should not be
> done at all.)

Well, for some definition of “badly,” I suppose. I'm pretty happy with MMD 
definition lists (with s/:/~/g), and with psql-style tables (mostly implemented 
in 
[Markdent::Dialect::Theory](http://search.cpan.org/perldoc?Markdent::Dialect::Theory).
 I find them both esthetically pleasing. I suppose it'd be for another thread 
to discuss the downsides you see, so feel free to ignore me.

Best,

David

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

Re: Markdown development

[Aristotle Pagaltzis]

* Lou Quillio  [2010-03-20 00:55]:
> Markdown's dead? Absurd.

Obviously. That’s why no one said that.

Markdown *development* is dead.

(Straw men are easy to clobber.)

> Markdown's huge, and in the form of PHP Markdown Extra is
> basically done. Done != dead, done == problem solved.

Fact: the latest Gruber release is a beta.

Fact: the latest official Gruber release is missing features
that Gruber himself uses.

You can argue about whether this means “done” – I see “scratches
my itch so I lost interest” –, but you cannot argue the facts.

Personally I think Markdown is still missing a lot of fit and
polish that could make it much (subtly) nicer still. (Eg. I’m
tired of using `` lines as a crutch to force consecutive,
separate blockquotes and lists to be recognised as such.)

What it’s not missing is big constructs. (I believe tables and
definition lists can only be done badly, and so should not be
done at all.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Markdown development

[Bowerbird]

lou said:
>   Markdown's dead?  Absurd.  Markdown's huge, 
>and in the form of PHP Markdown Extra is basically done. 
>   Done != dead, done == problem solved.

_your_ problem not necessarily included.   batteries sold separately.

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

Re: Markdown development

[Lou Quillio]

It's nowhere written that the Markdown user won't have to pre-process
or post-process to scratch his particular itch.

Michel has already[1] made the extensions and done the fixes that a
"text-to-HTML conversion tool for web writers" reasonably needs at its
core.  (Prefer Ruby?  kramdown's for you[2].)

Need more transforms?  Bolt 'em onto your stack.  Need an
auto-generated TOC?  How about HTML::Toc[3].  MathML?  ASCIIMathML[4]
and ASCIIMathPHP[5] work well.  Need a shoehorn for [insert special
need]?  That's why god gave you sed[6].

Somewhere around here I have the jewel case that my original Markdown
CD came in.  On the front it says "Wrapper script not included."
Evidently the print's too small, cuz we keep having threads like this.

Markdown's dead?  Absurd.  Markdown's huge, and in the form of PHP
Markdown Extra is basically done.  Done != dead, done == problem
solved.

LQ


[1]: http://michelf.com/projects/php-markdown/extra/
[2]: http://kramdown.rubyforge.org/
[3]: http://search.cpan.org/~fvulto/HTML-Toc-0.91/Toc.pod
[4]: http://www1.chapman.edu/~jipsen/mathml/asciimath.html
[5]: 
http://www.oldschool.com.sg/index.php/module/Shared/action/Static/tmpl/ASCIIMathPHP
[6]: http://en.wikipedia.org/wiki/Sed
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Yuri Takhteyev]

> undocumented - search the list archives for clues). Personally, I think this
> is where implementations should look to move next - not expanding the
> syntax, but providing an API so that it's users can in their own code to
> meet the specific needs of their specific projects.

And those two are directly connected, of course. The easier it is for
people to extend the syntax for their specific tools, the less need
they have for getting Markdown's common syntax extended.
.
- yuri
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Waylan Limberg]

On Wed, Mar 17, 2010 at 8:37 PM, Arno Hautala  wrote:
>
>
> Me?  I'm happy with PHPMDExtra.  And really that's just for the
> footnotes and definition lists.  Plenty of other forks support both.
> The headache is that so many support one convention but not another.
> It also emphasizes the point that this is Markdown, not HTML.  It
> can't and shouldn't support everything.  Take "Markdown in Python".
> Does a Markdown implementation really need to be able to output an
> image gallery [2], or RSS [3]?  Even the table syntax used by MDE
> gives me bad vibes.  If your table is simple enough to be defined in
> MDE, there's probably a better way to convey that data.  If it's
> complicated enough to stretch what MDE can do, you should probably
> just code the table.  Markdown is not always the right tool for the
> job.
>

For the record, we are dropping the Imagelinks extension completely from
Pyrton-Markdown. It never actually worked without some hard-to-find
no-longer-maintained third party code. It will be gone with the next
release. Both it and the RSS extension were proof of concepts to show what
our extension API "could" do - not that they should necessarily be something
we should do. They ended up being distributed with the core project ever
since and forgotten about. We recently deleted the Imagelinks extension when
someone complained it didn't work -- which reminded us it existed.  We
should probably do the same with the RSS extension. Especially now that we
have other, useful extensions (i.e.: extra [1]).

In fact, I've recently expounded [2] on why I think my code highlighting
extension [3] is no longer necessary, but that is probably one of our most
used extensions, so we'll continue to maintain it for the time being.

[1]: http://www.freewisdom.org/projects/python-markdown/Extra
[2]: http://achinghead.com/archive/88/syntax-highlighting-web/
[3]: http://www.freewisdom.org/projects/python-markdown/CodeHilite

So, I have to agree with Arno here. Adding more doesn't necessarily make
Markdown better. We've already tried it (as have many implementations) and
it doesn't always work. For example I wish I never would have released my
wikilinks extension. It has resulted in more feature creep type of requests
that anything else in the project. Personally, I don't even like wikilinks
for any purpose. But I digress.

The one thing we are proud of about Python-Markdown is the ease with which
anyone can write extensions of their own [4]. Although not quite
as versatile, PHP Markdown has started to follow suit (although mostly
undocumented - search the list archives for clues). Personally, I think this
is where implementations should look to move next - not expanding the
syntax, but providing an API so that it's users can in their own code to
meet the specific needs of their specific projects.

[4]: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions

-- 

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

Re: Markdown development

[Arno Hautala]

On Wed, Mar 17, 2010 at 02:56, Albert Skye  wrote:
>> Is there a way Gruber could "anoint" someone ...
>
> Yikes, this sounds ... ;}

A lot of this thread sounds :}
It's a solution looking for a problem.  Or at least a poor solution to
an undefined problem.
Though looking back I see several others with my core thought: the
current state of Markdown is pretty much good enough.


> I think the community can just cooperate and develop a common tool.

It seems to me that for the vast majority of users and uses, Markdown
is just fine.  The forks that have grown up either fill a niche or
have made some manner of incremental improvement.  Of course there is
room for further development and consolidation; but so far, what's
been suggested here mostly boils down to wishing that Gruber would
pick up development.


> A wiki (with Markdown syntax of course) might be useful for such development.

Why doesn't someone just start such a wiki?  Start with the reference
documentation and flesh it out where need be.  Add pages for
inconsistency, ambiguity, conflicts, etc.  Finally add in potential
for improvement.  Start with the forks and pick the common features or
those that would benefit the majority of users.  Actually start
working towards that standard.  Periodically, send a direct request
for Gruber's input.  If at any point he expresses... "a different
point of view" [1] and the community decides to move in a different
direction, then do it, but don't try to coyly reference that this is a
new version of Markdown.  Reference the heritage, and move on.

[1] http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001163.html


> It need not be called "Markdown" nor strictly supeset Markdown. It simply 
> needs to be useful to the community. It needs no *one* to control it but 
> without cooperation we may as well follow our own forks.

On Wed, Mar 17, 2010 at 10:55, Sherwood Botsford  wrote:
>
> If you want to be true to JG's heritage, he is asked to rule on any specific
> corner case of the original specification.  He's also asked to put a link to
> the MSG web site on his MD page.  This gives him a say in what happens, and
> is a graceful way for him to pass down his heritage without spending a lot
> of time involved with it.

If development on Markdown wants to see any sort recognition or
"blessing" from Gruber it would need to get him excited about the
project.  This means care paid to testing, documentation, and above
all else, syntax extensions that are sensible, clean, obvious, and
within scope.  I do not foresee this as the sort of project that will
be slapped together with "no *one* [in] control".  At the least it
needs one or two motivated individuals with the effort to sort through
all the forks, or the balls to ignore all that and just lay down what
makes sense.

Me?  I'm happy with PHPMDExtra.  And really that's just for the
footnotes and definition lists.  Plenty of other forks support both.
The headache is that so many support one convention but not another.
It also emphasizes the point that this is Markdown, not HTML.  It
can't and shouldn't support everything.  Take "Markdown in Python".
Does a Markdown implementation really need to be able to output an
image gallery [2], or RSS [3]?  Even the table syntax used by MDE
gives me bad vibes.  If your table is simple enough to be defined in
MDE, there's probably a better way to convey that data.  If it's
complicated enough to stretch what MDE can do, you should probably
just code the table.  Markdown is not always the right tool for the
job.

[2] http://www.freewisdom.org/projects/python-markdown/ImageLinks
[3] http://www.freewisdom.org/projects/python-markdown/RSS


On Wed, Mar 17, 2010 at 10:55, Sherwood Botsford  wrote:
>
> I think it wise to change the name, but it should be clearly derivative.
> E.g.
> * Markdown 2
> * Markdown II
> * Markdown NG
> * MarqueDown

May as well just go with "Suck it Gruber (beta)".  Derivative does not inspire.


-- 
arno  s  hautala/-|   a...@alum.wpi.edu

pgp eabb6fe6 d47c500f b2458f5d a7cc7abb f81c4e00
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Sherwood Botsford]

Getting agreement on the corner tests should be easy. Most of the time the
corner test is odd enough that it never came up in a production environment,
and so deciding one way or another is less likely to break something.

Having an MD compliance test may be *the* way to go.

MD has forked.  20 times or so.  No way we are going to stuff that many
worms back into the can.

An MD standard, and such things as this list can rationalize the situation.

The end result is that the testing group IS MD.  Everything else is
implementations of MD.

So it's called Markdown Standards Group, -- MSG for short.

One possibilitiy is that we end up with a test similar to the ACID browser
test that checks compliance with W3C standards.  You end up with a score.

Another possibility is that you have a web page where each implementation's
differences from the standard are shown.

If the 'market penetration' of MD can be determined for each flavour, then
any feature that is present in X% of the market becomes a 'core' feature.
The best way to determine market penetration is to encourage developers to
set up a list (how 'bouth this one...' and use a vote.  Implementors would
be encouraged to put contact info for thie list in their source code and
documentation.

For a given feature and implementation:
*  It's implemented as per core standard.
*  It's implemented with quirks.  Quirks can be edge behaviour with special
cases, html code that presents itself the same visually, but is different
behind the scenes.  E.g.  MMD ignores blocks encased in  as per
standard, but wraps  in  tags and processes everything inside
normally.  I like this quirk, but I could do without the  tags.
*  Normal behaviour is different, but can be brought to standard with flags
or a configuration file  This allows variant implementations to get accepted
status without breaking their established base.
*  It doesn't meet the standard at all.

If you want to be true to JG's heritage, he is asked to rule on any specific
corner case of the original specification.  He's also asked to put a link to
the MSG web site on his MD page.  This gives him a say in what happens, and
is a graceful way for him to pass down his heritage without spending a lot
of time involved with it.

I think also that any web site put up should acknowledge JG, and have a link
back to Daring Fireball.

I think it wise to change the name, but it should be clearly derivative.
E.g.
* Markdown 2
* Markdown II
* Markdown NG
* MarqueDown



Respectfully,

Sherwood of Sherwood's Forests

Sherwood Botsford
Sherwood's Forests --  http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0




On Wed, Mar 17, 2010 at 4:33 AM, yy  wrote:

> 2010/3/17 david parsons :
> >
> >   There are markdown implementations in a dozen languages.   I am
> >   unsure about how a common tool can be made here.
> >
>
> What I would really like to see is a standard test suite, with a given
> input and the expected output, which we can test against the different
> implementations. Then, we would only have to agree on a "core" set of
> tests that every implementation has to pass to be considered "markdown
> compatible" and we could easily add tests for non-standard features.
> The difficult part is to decide if the most strange corner cases are
> implementation dependent, or how they must be handled (since I expect
> some differences between current implementations). Mdtest is probably
> the best starting point for such a task.
>
> --
> - yy.
> ___
> 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: Markdown development

[yy]

2010/3/17 david parsons :
>
>   There are markdown implementations in a dozen languages.   I am
>   unsure about how a common tool can be made here.
>

What I would really like to see is a standard test suite, with a given
input and the expected output, which we can test against the different
implementations. Then, we would only have to agree on a "core" set of
tests that every implementation has to pass to be considered "markdown
compatible" and we could easily add tests for non-standard features.
The difficult part is to decide if the most strange corner cases are
implementation dependent, or how they must be handled (since I expect
some differences between current implementations). Mdtest is probably
the best starting point for such a task.

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

Re: Markdown development

[david parsons]

In article <20100316235613572049.1a73e...@yahoo.co.uk>,
Albert Skye   wrote:
>> Is there a way Gruber could "anoint" someone ...
>
>Yikes, this sounds ... ;}
>
>I think the community can just cooperate and develop a common tool.

   There are markdown implementations in a dozen languages.   I am
   unsure about how a common tool can be made here.


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

Re: Markdown development

[Albert Skye]

> Is there a way Gruber could "anoint" someone ...

Yikes, this sounds ... ;}

I think the community can just cooperate and develop a common tool.

It need not be called "Markdown" nor strictly supeset Markdown. It simply needs 
to be useful to the community. It needs no *one* to control it but without 
cooperation we may as well follow our own forks.

A wiki (with Markdown syntax of course) might be useful for such development.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Joseph Lorenzo Hall]

On Sat, Mar 6, 2010 at 2:34 PM, Michel Fortin  wrote:
> Is there anyone interested in sponsoring Markdown development? I think you 
> first need a solution to this problem if you want to have a lead designer.

Yikes, this sounds like an NGO (Mozilla Foundation, etc.) and overhead
(to accept support, etc.).

Is there a way Gruber could "anoint" someone with the relevant level
of interest and gruber-esque design+coding sense?  That could be
tough.  As someone who studies governance and policy, this is a sticky
situation... and one where the classic answer of "fork!" has already
been done a couple dozen times, without "answering" the problem.
best, Joe

-- 
Joseph Lorenzo Hall
ACCURATE Postdoctoral Research Associate
UC Berkeley School of Information
Princeton Center for Information Technology Policy
http://josephhall.org/
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[Michel Fortin]

Le 2010-03-06 à 11:56, Aristotle Pagaltzis a écrit :

> If Markdown is to evolve, this is the problem that needs to be
> solved: it needs a principal designer with a good enough sense
> for its spirit and enough of a voice to gain the authority to
> have his or her mandates followed.

I'm of the same opinion, although I'll say the problem goes a little deeper.

Personally, I see little to be gained by improving Markdown. This applies to 
myself, but probably to John Gruber too. There's not much more recognition I 
can get by improving PHP Markdown and very little money to make with it.

I'm still answering my emails about PHP Markdown, giving tips to whoever needs 
them, and I'm fixing bugs from time to time. But all this I do by charity: I 
don't gain anything personally or professionally by doing it except perhaps the 
goodwill of a few people. That could change if I were to return to web 
development, but right now I'm working on other things to pay the bills. I 
think John is in a similar situation.

Is there anyone interested in sponsoring Markdown development? I think you 
first need a solution to this problem if you want to have a lead designer.

-- 
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: Markdown development

[John MacFarlane]

+++ david parsons [Mar 06 10 07:07 ]:
> In article <20100306064636.ga17...@protagoras.phil.berkeley.edu>,
> John MacFarlane   wrote:
> 
> >./markdown -V
> >markdown: discount 1.6.2
> >./markdown
> >`hi
`
> >`hi`
> >
> >But you should get:
> >
> >hi

> >
> >--at least according to the reference implementation (and most
> >others). Backslashes don't escape `s inside code spans.
> 
>Backslash?   Wait, is that ^A I see supposed to be 
>the character 01h or a backslash?

It should be a backslash.  Not sure what happened there.

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

Re: Markdown development

[Aristotle Pagaltzis]

* Fletcher T. Penney  [2010-03-06 00:00]:
> The point is that each of these variant forms of Markdown
> evolved to scratch someone's particular itch.

As indeed did Markdown himself. Once it scratched John’s own
itch well enough, he lost the compulsion to improve it. Which
I can relate to very well – a lot of my personal projects end up
this way.

The problem we are having is that by virtue of being the
principal designer of Markdown, he is also the only one with the
authority to set a direction and have all implementations
unilaterally follow it. Michel Fortin is probably the only one in
an at all comparable position.

Personally I find most extensions to Markdown lacking in that
ineffable spirit that ties Markdown together. But I’m pretty
sure that the designers of these extensions disagree, and would
in turn find my proposals lacking.

And if that is the case, then I’d be even less likely to want
anything that any likely committee would cook up.

This is why the fact that Gruber himself no longer participates
causes a problem for everyone else who is invested in Markdown:
there is no longer a central voice.

But Gruber created what he did, and shared it, and he marketed it
(and very successfully, as we all are proof of) for what it was.
That no one else has had the same success in pushing their own
evolution of the format does not oblige Gruber to anything.

If Markdown is to evolve, this is the problem that needs to be
solved: it needs a principal designer with a good enough sense
for its spirit and enough of a voice to gain the authority to
have his or her mandates followed.

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

Re: Markdown development

[Aristotle Pagaltzis]

* david parsons  [2010-03-06 05:25]:
> In article <20100306020548.gb...@protagoras.phil.berkeley.edu>,
> John MacFarlane   wrote:
> >`` a```a ``
> >
> >should render as
> >
> >a```a
>
> Now that's a defect all right. It looks like the reference
> matches any run of ticks, not just the one or two that I read
> from the standard.

According to the spec it *is* supposed to match any number of
ticks – but they are supposed to be the *same* number on both
ends.

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

Re: [Bulk] Re: Markdown development

[Albert Skye]

> See this: http://github.github.com/github-flavored-markdown/
> 
> I think their assumptions about newlines is way off.

I don't know about their assumptions but I do know that I prefer that behaviour 
and it was one of the first departures I made from Markdown syntax.

When I insert a newline in my text, I mean for it to remain. I don't hard wrap 
my e-mail or other text.

The fixed-width character column can be useful but the paradigm is also brittle 
and pernicious; better to make things work without it because it smells really 
bad too.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[david parsons]

In article <20100306064636.ga17...@protagoras.phil.berkeley.edu>,
John MacFarlane   wrote:

>./markdown -V
>markdown: discount 1.6.2
>./markdown
>`hi
`
>`hi`
>
>But you should get:
>
>hi

>
>--at least according to the reference implementation (and most
>others). Backslashes don't escape `s inside code spans.

   Backslash?   Wait, is that ^A I see supposed to be 
   the character 01h or a backslash?

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

Re: Markdown development

[John MacFarlane]

+++ david parsons [Mar 06 10 04:33 ]:
> In article <20100306020548.gb...@protagoras.phil.berkeley.edu>,
> John MacFarlane   wrote:
> 
> >`a
`
> >
> >should render as
> >
> >a

> >
> >but discount (at least the version on babelmark) renders it as
> 
> The version on Babelmark might be a little out of date; the
> 1.6 series doesn't leave that tick hanging.

Although discount 1.6.2 doesn't leave the tick hanging, it's still not
right, I think:

./markdown -V
markdown: discount 1.6.2
./markdown
`hi\`
`hi`

But you should get:

hi\

--at least according to the reference implementation (and most
others). Backslashes don't escape `s inside code spans.

John

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

Re: Markdown development

[Thomas Leitner]

> I'd like to see the community cooperate toward a specification which
> addresses the shortcomings and ambiguities of Markdown (even if it
> need be released under a new name).

Not a spec for Markdown itself, but for a superset of Markdown:

http://kramdown.rubyforge.org/syntax.html

I tried to address most ambiguities, especially in list parsing.

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

Re: Markdown development

[Waylan Limberg]

On Fri, Mar 5, 2010 at 5:10 PM, david parsons  wrote:
> In article <20100305211753.ga27...@protagoras.phil.berkeley.edu>,
> John MacFarlane   wrote:
>>Currently big players like reddit and github
>>use forms of markdown that depart significantly from John Gruber's
>>official specification;
>
>     Okay, I'm curious.   Since I'm the writer of the "forms of markdown"
>     that reddit and github use, just exactly where does discount depart
>     significantly from JG's official specification?

See this: http://github.github.com/github-flavored-markdown/

I think their assumptions about newlines is way off. But otherwise,
the additions they added make sense in the context of that site.

-- 

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

Re: Markdown development

[david parsons]

In article <20100306020548.gb...@protagoras.phil.berkeley.edu>,
John MacFarlane   wrote:

>`a
`
>
>should render as
>
>a

>
>but discount (at least the version on babelmark) renders it as

The version on Babelmark might be a little out of date; the
1.6 series doesn't leave that tick hanging.

>`` a```a ``
>
>should render as
>
>a```a

Now that's a defect all right.   It looks like the reference
matches any run of ticks, not just the one or two that I read
from the standard.

That's easy to fix.  Harder if I want it to be elegant, but
still easy.   It will give me an excuse to release a 1.6.3
sometime next week.

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

Re: Markdown development

[John MacFarlane]

+++ John MacFarlane [Mar 05 10 18:05 ]:
> +++ david parsons [Mar 05 10 22:10 ]:
> > In article <20100305211753.ga27...@protagoras.phil.berkeley.edu>,
> > John MacFarlane   wrote:
> > >Currently big players like reddit and github
> > >use forms of markdown that depart significantly from John Gruber's
> > >official specification;
> > 
> >  Okay, I'm curious.   Since I'm the writer of the "forms of markdown"
> >  that reddit and github use, just exactly where does discount depart
> >  significantly from JG's official specification?
> 
> Oh, I didn't know that either of those sites used discount.
> Discount is, in my experience, extremely accurate (and extremely
> fast). But github uses a documented variant for some purposes
> (http://github.github.com/github-flavored-markdown/), and, as for
> reddit, I'm just going on my experience having posts there formatted
> incorrectly. I think one context where that happened was an inline
> code span with backslashes. According to John Gruber's specification, as
> I understand it,
> 
> `a\`
> 
> should render as
> 
> a\
> 
> but discount (at least the version on babelmark) renders it as
> 
> a\`
> 
> Similarly,
> 
> `` a```a ``
> 
> should render as
> 
> a```a
> 
> but discount renders it as
> 
> aa

Okay, looking back at the actual [spec]
(http://daringfireball.net/projects/markdown/syntax#code),
I see that it was unfair of me to suggest that discount does
not satisfy it.  The spec is just too vague. For example, it never says
explicitly that backslash escapes don't work inside code spans (though
perhaps that's implicit, since if backslash escapes worked, you wouldn't
need the more complex method of using multiple-backtick delimiters).
I guess my interpretation of it was influenced by seeing what
Markdown.pl actually does.

Indeed, in one respect, discount conforms to the spec for inline
code spans better than Markdown.pl.  The syntax document says:
"The backtick delimiters surrounding a code span may include spaces — one
after the opening, one before the closing."  I'd not noticed this
before, but this seems to say pretty unambiguously that there is
*one* optional space at each end. Markdown.pl, and all other
implementations except discount (and the most recent lunamark, which I
just updated), gobble any number of spaces at the beginning and end
of a code span.

Test case:  `  hello  `

John

PS.  I've now fixed the problem with
`` this```case ``
in lunamark and peg-markdown.

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

Re: Markdown development

[Chad Nelson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Yuri provided some good reading, but I thought it important to point
> out a specific comment by J.G. regarding the name of such a project:
> 
> http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001189.html

That's only a problem if he "despises" whatever we come up with. :-)

There are certainly a few additional things I'd like to see in Markdown,
but my biggest irritation is the ambiguity of the syntax. (I only recall
one at the moment, but I ran into many of them while developing my
implementation.) Just clarifying those places would be a huge plus.

On the other hand, as has been mentioned, they only arise in fairly rare
edge cases, so I might just have to live with them. It just feels
*messy* with those in there.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRxVQACgkQp9x9jeZ9/wSUNACfRkZc0ARNdqY9IBod7LUE0bpD
7XMAoNCfRuaQf0J0pgPMD0S0KI/BeEQx
=hTKu
-END PGP SIGNATURE-
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown development

[John MacFarlane]

+++ david parsons [Mar 05 10 22:10 ]:
> In article <20100305211753.ga27...@protagoras.phil.berkeley.edu>,
> John MacFarlane   wrote:
> >Currently big players like reddit and github
> >use forms of markdown that depart significantly from John Gruber's
> >official specification;
> 
>  Okay, I'm curious.   Since I'm the writer of the "forms of markdown"
>  that reddit and github use, just exactly where does discount depart
>  significantly from JG's official specification?

Oh, I didn't know that either of those sites used discount.
Discount is, in my experience, extremely accurate (and extremely
fast). But github uses a documented variant for some purposes
(http://github.github.com/github-flavored-markdown/), and, as for
reddit, I'm just going on my experience having posts there formatted
incorrectly. I think one context where that happened was an inline
code span with backslashes. According to John Gruber's specification, as
I understand it,

`a\`

should render as

a\

but discount (at least the version on babelmark) renders it as

a\`

Similarly,

`` a```a ``

should render as

a```a

but discount renders it as

aa

(Hm, just noticed that peg-markdown and lunamark get that one wrong,
too. I'll have to fix that. At least pandoc gets it right.)

John

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

Re: Markdown development

[Fletcher T. Penney]

When I first started to write MultiMarkdown, I hoped it would become
obsolete when the official markdown spec included footnotes and
possibly tables.  Then I added a few other features, and it also
became clear that Markdown wasn't going to evolve any further in an
official capacity.


Which is not necessarily a bad thing.  The basic markdown syntax is
good.  We all use it because we think it's the best markup language
out there, and those of us who extended it do it because we think it
would be the perfect markup language with just one or two new
features  That doesn't mean that the core markdown syntax needs to
add those features.


What I would like to see is the following:

1) Fix the syntax specification for the one or two edge cases that
lead to unintentionally different outputs from various markdown
implementations (e.g. nested lists).  It would be nice to have a stamp
of approval from Gruber on this part

2) Develop an opt-in "consortium" or whatever that would allow the
most common add-on features (e.g. footnotes) to have a well thought
out specification that could be consistent across those markdown
implementations that wanted to include them.  This would not be
interpreted as an official "markdown 2.0" or anything like that -
simply that it would be nice if the various markdown derivatives could
be as cross-compatible as possible.  I suspect this list of new
features would be rather short - there are likely several features in
MMD, for instance, that don't need to be included in other flavors
(e.g. citations, asciimathml, etc)


The point is that each of these variant forms of Markdown evolved to
scratch someone's particular itch.  It would be nice to standardize
the areas that overlap, but there's no need to limit the various
alternative features that are only needed by a few people.


Just my $.02


F-


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

Re: Markdown development

[david parsons]

In article <20100305211753.ga27...@protagoras.phil.berkeley.edu>,
John MacFarlane   wrote:
>Currently big players like reddit and github
>use forms of markdown that depart significantly from John Gruber's
>official specification;

 Okay, I'm curious.   Since I'm the writer of the "forms of markdown"
 that reddit and github use, just exactly where does discount depart
 significantly from JG's official specification?

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

Re: Markdown development

[John MacFarlane]

+++ Yuri Takhteyev [Mar 05 10 14:27 ]:
> > I'll second that. Though it would be best if we could still use the
> > Markdown name; a different one would just make one more confusing
> > text-markup specification for people to ignore. If we could call it
> > Markdown2 or something similar, it would be obvious that it expands on,
> > and supersedes, the original Markdown.
> 
> Required reading:
> 
> http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1021
> http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1031
> http://six.pairlist.net/pipermail/markdown-discuss/2008-March/thread.html
> 
> Of course, there are many many other relevant threads, but this would
> give you a taste.

A lot has happened since early 2008. For example, we now have
two implementations based on a PEG, which could serve as a basis for
a formal specification of markdown's grammar:

http://github.com/jgm/lunamark
grammar: http://github.com/jgm/lunamark/blob/master/lunamark/parser/markdown.lua

http://github.com/jgm/peg-markdown
grammar: http://github.com/jgm/peg-markdown/blob/master/markdown_parser.leg

(Of course, this is just my interpretation of the markdown syntax
specification, which leaves a lot undecided.)

The main problem is political.  After following this group for several
years, I'm doubtful that we'd be able to come to consensus about a
grammar.  Perhaps we could agree on a process, with a voting system for
deciding disputed issues and a mechanism for deciding on extensions.
But that's a big undertaking, and it's not clear what authority such
decisions would have.  Currently big players like reddit and github
use forms of markdown that depart significantly from John Gruber's
official specification; if they're going to ignore that, then I'm
guessing they'd also ignore a more detailed grammar devised by a
markdown working group.

John

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

Re: Markdown development

[david parsons]

In article <20100305103250714488.32875...@yahoo.co.uk>,
Albert Skye   wrote:
>Not only is [Markdown] dead, it's starting to smell really bad. (Apologies to 
>Pike.)

There are some hilarious edge/pathological cases which Markdown.pl doesn't 
get
right, but for the most part it works and if the places where it doesn't 
work
are offensive, there are literally dozens of other implementations out there
that have been tweaked more recently than Markdown.pl

>It's author appears to have little interest in developing the tool and
>participating in the community which uses it.

He's got a Perl implementation that works for him, and there are many
other implementations that are basically compatable with his code &
test suites.   There's not much he needs to do, so why should he run
around and do busywork?

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

Re: Markdown development

[Waylan Limberg]

On Fri, Mar 5, 2010 at 2:27 PM, Yuri Takhteyev  wrote:
>> I'll second that. Though it would be best if we could still use the
>> Markdown name; a different one would just make one more confusing
>> text-markup specification for people to ignore. If we could call it
>> Markdown2 or something similar, it would be obvious that it expands on,
>> and supersedes, the original Markdown.
>
> Required reading:
>
> http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1021
> http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1031
> http://six.pairlist.net/pipermail/markdown-discuss/2008-March/thread.html
>
> Of course, there are many many other relevant threads, but this would
> give you a taste.
>
> - yuri

Yuri provided some good reading, but I thought it important to point
out a specific comment by J.G. regarding the name of such a project:

http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001189.html

If anyone wants to undertake this effort, they may say it is "inspired
by markdown" but they are going to have to name is something
different. I get the impression that the name "Markdown2" is not quite
different enough here.

There's another interesting comment he made regarding a specific
markdown implementation here:

http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001163.html

I don't point these comments out to discourage such an effort from
happening (maybe it should).  However, if it does happen, imo it will
either need J.G.'s blessing or will need to happen separate from this
community/list. Although, I would imagine an announcement of and link
to such an effort wouldn't be objectionable.

Additionally, I did not point those comments out in an effort to
reflect negatively on J.G. He created Markdown and is entirely
entitled to such a position. I would very likely take a simple
position if I was in his shoes and/or shared his opinion. Currently,
my opinion regarding the need for a fork/restart/refresh is
'undecided'.

-- 

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

Re: Markdown development

[Yuri Takhteyev]

> I'll second that. Though it would be best if we could still use the
> Markdown name; a different one would just make one more confusing
> text-markup specification for people to ignore. If we could call it
> Markdown2 or something similar, it would be obvious that it expands on,
> and supersedes, the original Markdown.

Required reading:

http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1021
http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1031
http://six.pairlist.net/pipermail/markdown-discuss/2008-March/thread.html

Of course, there are many many other relevant threads, but this would
give you a taste.

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

Re: Markdown development

[Chad Nelson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> I'd like to see the community cooperate toward a specification which
> addresses the shortcomings and ambiguities of Markdown (even if it
> need be released under a new name). 

I'll second that. Though it would be best if we could still use the
Markdown name; a different one would just make one more confusing
text-markup specification for people to ignore. If we could call it
Markdown2 or something similar, it would be obvious that it expands on,
and supersedes, the original Markdown.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRUZ8ACgkQp9x9jeZ9/wThdgCgvtogv2EWD8ooaXZAvWNUDrf0
kowAnjuoh9F9HmXJMGN3neAOauQG8AEP
=72Eb
-END PGP SIGNATURE-
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Markdown development

[Albert Skye]

Not only is [Markdown] dead, it's starting to smell really bad. (Apologies to 
Pike.)

It's author appears to have little interest in developing the tool and 
participating in the community which uses it.

I'd like to see the community cooperate toward a specification which addresses 
the shortcomings and ambiguities of Markdown (even if it need be released under 
a new name).
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss