Re: markdown do not support Strikethrough ?

[David Chambers]

 and  have been deprecated since HTML 4.01. What HTML would you
expect Markdown to generate? Something like…

This is wrong. This is right.

or…

This is wrong. This is right.

But the above should really make use of  as well…

This is wrong. This is right.

This is well and truly beyond the scope of Markdown. Don't forget that HTML
is a subset of Markdown, so any time you want to do something without
corresponding Markdown syntax you can simply use HTML. So, you could have
something like this…

* first list item
* second list item
* fifth third list item

which'd convert to…


first list item
second list item
fifth third list item


David


On 22 July 2010 22:11, Chunlin Zhang  wrote:

> I am using indefero,and its wiki use markdown as wiki syntax,and I found
> that
> markdown do not support Strikethrough ?
> Thanks!
>
> ___
> 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 do not support Strikethrough ?

[David Chambers]

It may not allow raw HTML to be used. This is a limitation imposed by the
implementation, not by Markdown itself.


On 23 July 2010 13:36, Chunlin Zhang  wrote:

> David Chambers  gmail.com> writes:
>
> > * first list item
> > * second list item
> > * fifth third list item
> I tested in indefero wiki and found that both  and 
> not
> work,or I should report issue to indefero.
>
> Thanks.
>
> ___
> 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: HTML::StripScripts and markdown incompatibilities

[David Chambers]

Louis-David Mitterrand

> wrote:

Should I save the raw unfiltered post to DB and then (1) expand markdown and
> (2) filter with StripScripts only when _displaying_ the post? That would
> entail keeping some potentially "unclean" posts in the DB and having to
> StripScripts them repeatedly.


In my opinion the optimal solution is to save each post as is (i.e. as
Markdown), convert the post to HTML when required, strip nasties, and *cache
the result*. This is the approach I employ in Mango ,
and it seems to work well.

David


On 25 August 2010 00:49, Louis-David Mitterrand <
vindex+lists-markdown-disc...@apartia.org
> wrote:

> On Tue, Aug 24, 2010 at 08:41:05AM -0400, Michel Fortin wrote:
> > Le 2010-08-24 à 8:27, Louis-David Mitterrand a écrit :
> >
> > > I'm using perl's HTML::StripScripts to clean out unwanted/broken html
> > > from forum post on my web site but it also removes  >
> > > or  markdown constructs.
> > >
> > > Any idea how to make these two live together in harmony?
> >
> > Are you calling StripScripts before or after Markdown? You should
> > always filter tags after converting to HTML, as it seems StripScripts
> > was designed to filter HTML, not Markdown-formatted text.
> >
> > Long explanation:
> > 
>
> Actually I save the forum posts to the DB in non-converted markdown and
> filtered of any unwanted html.
>
> Should I save the raw unfiltered post to DB and then (1) expand markdown
> and (2) filter with StripScripts only when _displaying_ the post? That
> would entail keeping some potentially "unclean" posts in the DB and
> having to StripScripts them repeatedly.
>
> --
> http://www.cruisefish.net
> ___
> 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

Video syntax

[David Chambers]

I'm planning to update Mango  to facilitate adding
video to Markdown documents. At the moment, of course, it's possible to
include video by including the appropriate HTML. There are three reasons,
though, that having syntax (official or unofficial) for video is a good
idea:

   - *Simplicity.* Writing something like [youtube:gPbh6Ru7VVM] is easy.
   Including half a dozen lines of HTML is much less so.
   - *Readability.* Gruber created Markdown not just because he wanted to
   avoid writing markup – he wanted to avoid *reading* it, too!
   - *Separation of concerns.* Documents should provide for each video just
   a link (and optionally alt text) the way they do for images. This way, the
   application can take on the responsibility of generating the appropriate
   markup. This is tremendously beneficial: HTML5 video is still relatively
   new, sites are being updated to take advantage of native video, and new
   video formats are emerging. Given this moving target it's difficult to be
   sure that hard-coded video markup will remain correct a year from now.
   Handing this responsibility to the application means that all video markup
   on a site can be updated with a single update to the application.

My question is, *has anyone given thought to an appropriate syntax for video
in Markdown?* We're a long way (five years, at least) from being at the
point where `` will be sufficient to get
the job done, so this probably isn't something that Markdown itself will
include for quite some time. I'm nonetheless interested to hear others'
thoughts as to what an appropriate syntax might be.

Currently, we have:

[link text](/path/to/link) for links, and

![alt text](/path/to/image) for images.

Clearly one option is to use the same syntax as for images but with an extra
`!`, but what would we use for audio in that case? `!!!` would be
ridiculous.

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

Re: Video syntax

[David Chambers]

On 16 September 2010 05:33, Waylan Limberg  wrote:

The fact is, when I go back up and reread this message and get to the source
>  tag, all I see is ` video which gets inserted in the document" and I skip to the next block. It
> doesn't really make reading the document any more painful or difficult.  And
> when writing, well, we need to include all that metadata anyway.


You make two excellent points here, Waylan, and I agree on both counts.

That said, I'm still keen to add some sort of support for shorthand to
Mango, as I personally would find this very helpful. The following, taken
from a post I wrote a year ago on embedding YouTube clips using valid XHTML
markup<http://davidchambersdesign.com/embed-youtube-clips-using-valid-xhtml-markup/>,
provides useful context:

http://www.youtube.com/v/video_id&hl=en&fs=1&rel=0";>
http://www.youtube.com/v/video_id&hl=en&fs=1&rel=0"; />



While this has not been updated to make use of the `video` element, it
demonstrates that the potential value of some sort of find and replace
mechanism. After all, that's exactly what I've been doing manually for the
last year: to embed a YouTube video I've pasted in the above snippet and
done a find and replace on "video_id". Since I'm styling the `object` via
CSS, I don't even include width and height.

Of course, this markup applies to YouTube but may not apply to other
services. That being the case, though, I'd still benefit from a `youtube:`
solution since 80% or more of the videos I embed are YouTube videos. The
fact that I'd need to include HTML for the other 20% does not deter me.

One thing that I'd like to make clear, Waylan, is that I'm raising the issue
on this list because it's a great place for such a discussion, *not* because
I'm expecting any of the Markdown implementations to support such syntax.

Last night another option occurred to me: `[Video: Soda Pop Stop](
http://www.youtube.com/v/gPbh6Ru7VVM)`.

The reason that I find this option so appealing is that the above remains
valid Markdown in non-Mango contexts. Mango will perform preprocessing to
convert this to the appropriate video markup, but without this preprocessing
the line would simply be converted to a descriptive link.

Sure, you could implement `![alt text](somerandomsite:key)`, but do you
> really want to update your code to support every new video host that comes
> along? Or would you provide some api by which the user could define his own?
> I don't know about you, but every time I link to some new video host from my
> blog, I don't want to have to update my code (even if I wrote it all myself)
> so markdown knows about the new site.


Django (on which Mango is built) offers a simple solution. Mango could, for
example, ship with three templates to handle video: video.html, vimeo.html,
and youtube.html. It could parse the video URLs to determine whether to
apply the YouTube template, the Vimeo template, or the generic (fallback)
template. Users would have the freedom both to add templates for other hosts
and to override the bundled templates.

I agree that updating application code to facilitate the embedding of
possibly just a single video is unreasonable, so I'll stick to pasting in
HTML in these cases.

David


On 16 September 2010 06:05, david parsons  wrote:

> On Thu, Sep 16, 2010 at 01:33:49AM +1200, David Chambers wrote:
> > I'm planning to update Mango <http://mango.io/wtf?> to facilitate adding
> > video to Markdown documents. At the moment, of course, it's possible to
> > include video by including the appropriate HTML. There are three reasons,
> > though, that having syntax (official or unofficial) for video is a good
> > idea:
> >
> >- *Simplicity.* Writing something like [youtube:gPbh6Ru7VVM] is easy.
> >Including half a dozen lines of HTML is much less so.
>
>  I don't know if it's feasable until a standard way of doing video
>  emerges and the video-station websites start following it.  A html5
>   block is lovely, but it's not very useful until the bulk of
>  the web world can deal with it without complaint.
>
> > My question is, *has anyone given thought to an appropriate syntax for
> video
> > in Markdown?*
>
>Sure.   We've got the framework for it:
>
>[text](object:[content-type:]url [=size] ['comment'])
>
>And then you can do something like
>
>[![no support for this content
> here](sorry.gif)](video:x-shockwave-flash:
> http://www.youtube.com/v/oFHSZLIOLZs =425x328 'this may not be terse, but
> at least it's not naked html')
>
>[Honk!](audio:/~orc/klaxon.wav)
>
>
>without introducing (another form of) ascii spaghetti to the language

Re: Video syntax

[David Chambers]

On 16 September 2010 13:32, Waylan Limberg  wrote:

An interesting thought just occurred to be when re-reading this. Why do you
> need any special syntax at all? Why not just:


>[Soda Pop Stop](http://www.youtube.com/v/gPbh6Ru7VVM )


> Just parse the urls for "youtube.com" (or "vimeo" etc) and when
> found, convert to an appropriate object. It's easy, simple and introduces
> no new syntax of any kind.


Brilliant suggestion, Waylan! I'd been thinking that providing a default
replacement for unrecognized video hosts would be helpful (the `[Vv]ideo:`
syntax would enable this), but you've convinced me otherwise. By using
standard link syntax, the fact that Mango will replace a link to a YouTube
video with the markup necessary to embed that video will be a magical
special case, whereas using `[Vv]ideo:` would set the unreasonable
expectation (as you so rightly point out) that any video should work.

Thanks everyone, for your input. I'll run with the standard link approach,
and add to Mango special rules for handling youtube.com video links.

David


On 16 September 2010 13:32, Waylan Limberg  wrote:

> On Wed, Sep 15, 2010 at 9:24 PM, Waylan Limberg  wrote:
> > While I realize youtube can be extracted from parsing the url, by
>
> An interesting thought just occurred to be when re-reading this. Why
> do you need any special syntax at all? Why not just:
>
>[Soda Pop Stop](http://www.youtube.com/v/gPbh6Ru7VVM )
>
> Just parse the urls for "youtube.com" (or "vimeo" etc) and when found,
> convert to an appropriate object. It's easy, simple and introduces no
> new syntax of any kind.
>
> --
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> 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: Video syntax

[David Chambers]

On 16 September 2010 21:10, Allan Odgaard wrote:

There is a difference between a link and an embedded object.


> Presently we have `[…](…)` for links and `![…](…)` for embedded objects
> (limited to images).


> I therefor not only think it would be more appropriate to use the `![…](…)`
> syntax for embedding video/audio, but by using the `[…](…)` syntax with
> auto-detection, you make it impossible for users to link to the resource
> (rather than embed it).


You make two very good points, Allan. Regarding the first – that it's useful
to maintain a clear syntactic distinction between links and embedded objects
– I agree in principle. The drawback of such an approach, however, is that
it necessitates the use of syntax which will be incorrectly interpreted by
all existing Markdown implementations. If we were to use the image syntax,
for example, a standard Markdown processor would produce *image* markup.
Were we to use a slightly modified version of the image syntax to avoid this
incorrect interpretation, a standard Markdown processor would likely leave
the input unchanged.

The nice thing about using standard link syntax is that the fallback is a
descriptive link – completely acceptable in my opinion. A trade-off exists
between semantically-correct syntax and interoperability. The side of the
divide on which one stands depends on how highly one values each of these
concerns.

I believe that your second point – that it needs to remain possible to *link
to* a video – is more easily solved. *Links* to videos will almost always
appear inline within a body of text; embedded videos, on the other hand,
will not. I'll provide two examples to illustrate my point.


*Example 1*

You must check out [Soda Pop Stop][1]. It's a short documentary about a
store in LA which sells nothing but soda.

[1]: http://www.youtube.com/v/gPbh6Ru7VVM


*Example 2*

# Soda Pop Stop

A short documentary about a store in LA which sells nothing but soda.

[Soda Pop Stop][1]

[1]: http://www.youtube.com/v/gPbh6Ru7VVM


I would expect the first to be converted to a link and the second to be
converted to embedding markup (by Mango) or to a link (by standard Markdown
processors). Distinguishing between the two cases using a regular expression
is straightforward. If one *wanted* to include a link to a video on its own
line, one could simply add a full stop (.) at the end of the line. Things
get a bit murky when one considers the possibility of allowing embedded
video within other elements (such as lists and blockquotes), so initially I
plan to insert embedding markup only in the straightforward situation
demonstrated above.


On 16 September 2010 21:10, Allan Odgaard <
1edf4d33-d1b1-4c97-a393-3d2b4ee5e095+markd...@uuid-mail.com<1edf4d33-d1b1-4c97-a393-3d2b4ee5e095%2bmarkd...@uuid-mail.com>
> wrote:

> On 16 Sep 2010, at 03:32, Waylan Limberg wrote:
>
>  […] Just parse the urls for "youtube.com" (or "vimeo" etc) and when
>> found, convert to an appropriate object. It's easy, simple and introduces no
>> new syntax of any kind.
>>
>
> There is a difference between a link and an embedded object.
>
> Presently we have `[…](…)` for links and `![…](…)` for embedded objects
> (limited to images).
>
> I therefor not only think it would be more appropriate to use the `![…](…)`
> syntax for embedding video/audio, but by using the `[…](…)` syntax with
> auto-detection, you make it impossible for users to link to the resource
> (rather than embed it).
>
>
> ___
> 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: Video syntax

[David Chambers]

I've just committed this change (commit
390<http://bitbucket.org/davidchambers/mango/changeset/58b16fcfea96#chg-models.py_newline159>).
Mango now replaces non-inline YouTube links with embedded video markup.

To see an example visit
http://davidchambers.name/blog/soda-pop-stop/m/(Markdown).

Then, strip the "m/" from the URL to see the the HTML version.

After some deliberation I elected to use YouTube's iframe embedding
method<http://apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html>as
it serves either HTML5 video or Flash as appropriate. Since the markup
is
generated by a Django template, though, it's easily customized.

Although I've gone to quite a bit of trouble to accommodate just a single
service, it's certainly nice to be able to write…

[Soda Pop Stop](http://www.youtube.com/watch?v=gPbh6Ru7VVM)

… and be done!

David


On 16 September 2010 21:56, David Chambers wrote:

> On 16 September 2010 21:10, Allan Odgaard wrote:
>
> There is a difference between a link and an embedded object.
>
>
>> Presently we have `[…](…)` for links and `![…](…)` for embedded objects
>> (limited to images).
>
>
>> I therefor not only think it would be more appropriate to use the
>> `![…](…)` syntax for embedding video/audio, but by using the `[…](…)` syntax
>> with auto-detection, you make it impossible for users to link to the
>> resource (rather than embed it).
>
>
> You make two very good points, Allan. Regarding the first – that it's
> useful to maintain a clear syntactic distinction between links and embedded
> objects – I agree in principle. The drawback of such an approach, however,
> is that it necessitates the use of syntax which will be incorrectly
> interpreted by all existing Markdown implementations. If we were to use the
> image syntax, for example, a standard Markdown processor would produce *
> image* markup. Were we to use a slightly modified version of the image
> syntax to avoid this incorrect interpretation, a standard Markdown processor
> would likely leave the input unchanged.
>
> The nice thing about using standard link syntax is that the fallback is a
> descriptive link – completely acceptable in my opinion. A trade-off exists
> between semantically-correct syntax and interoperability. The side of the
> divide on which one stands depends on how highly one values each of these
> concerns.
>
> I believe that your second point – that it needs to remain possible to *link
> to* a video – is more easily solved. *Links* to videos will almost always
> appear inline within a body of text; embedded videos, on the other hand,
> will not. I'll provide two examples to illustrate my point.
>
>
> *Example 1*
>
> You must check out [Soda Pop Stop][1]. It's a short documentary about a
> store in LA which sells nothing but soda.
>
> [1]: http://www.youtube.com/v/gPbh6Ru7VVM
>
>
> *Example 2*
>
> # Soda Pop Stop
>
> A short documentary about a store in LA which sells nothing but soda.
>
> [Soda Pop Stop][1]
>
> [1]: http://www.youtube.com/v/gPbh6Ru7VVM
>
>
> I would expect the first to be converted to a link and the second to be
> converted to embedding markup (by Mango) or to a link (by standard Markdown
> processors). Distinguishing between the two cases using a regular expression
> is straightforward. If one *wanted* to include a link to a video on its
> own line, one could simply add a full stop (.) at the end of the line.
> Things get a bit murky when one considers the possibility of allowing
> embedded video within other elements (such as lists and blockquotes), so
> initially I plan to insert embedding markup only in the straightforward
> situation demonstrated above.
>
>
> On 16 September 2010 21:10, Allan Odgaard <
> 1edf4d33-d1b1-4c97-a393-3d2b4ee5e095+markd...@uuid-mail.com<1edf4d33-d1b1-4c97-a393-3d2b4ee5e095%2bmarkd...@uuid-mail.com>
> > wrote:
>
>> On 16 Sep 2010, at 03:32, Waylan Limberg wrote:
>>
>>  […] Just parse the urls for "youtube.com" (or "vimeo" etc) and when
>>> found, convert to an appropriate object. It's easy, simple and introduces no
>>> new syntax of any kind.
>>>
>>
>> There is a difference between a link and an embedded object.
>>
>> Presently we have `[…](…)` for links and `![…](…)` for embedded objects
>> (limited to images).
>>
>> I therefor not only think it would be more appropriate to use the
>> `![…](…)` syntax for embedding video/audio, but by using the `[…](…)` syntax
>> with auto-detection, you make it impossible for users to link to the
>> resource (rather than embed it).
>>
>>
>> ___
>> 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: Video syntax

[David Chambers]

Hi David,

The URL you received is not (quite) the one I sent. There was (at my end) a
space between the URL and "(Markdown)". The correct address is
http://davidchambers.name/blog/soda-pop-stop/m/.

David


On 19 September 2010 01:22, David Herren  wrote:

> Don't know about anyone else, but these links are failing at present.
>
> On Sep 17, 2010, at 10:18 PM, David Chambers wrote:
>
> > To see an example visit
> > http://davidchambers.name/blog/soda-pop-stop/m/(Markdown).
> >
> > Then, strip the "m/" from the URL to see the the HTML version.
>
>
> /david
>
> --
> david herren - shoreham, vt, us na terra solsys orionarm
>
> Some people have a mental horizon of radius zero, and call it their point
> of view. -- David Hilbert
>
> ___
> 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: Any way to get syntax-highlighted code blocks with Text::MultiMarkdown?

[David Chambers]

I'm not familiar with Text::MultiMarkdown, but I can say that I've found
google-code-prettify  to be
a good fit with Markdown due to the fact that it acts upon vanilla 
blocks (unlike SyntaxHighlighter, for example, which only acts upon elements
with a particular class name.

If you're interested in seeing this duo in action, have a look at:

   - http://dċd.ws/70/  *(the rendered page with
   highlighting)*
   - http://dċd.ws/70/m/  *(the page's Markdown)
   *

David


On 3 December 2010 10:40, Mike Doherty  wrote:

> Hello,
>
> I'm using Text::MultiMarkdown in my website, and I would like to know if
> there is any way to get syntax highlighting in code blocks.
>
> Thanks,
> -Mike Doherty
> ___
> 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: Any way to get syntax-highlighted code blocks with Text::MultiMarkdown?

[David Chambers]

Mike Doherty wrote:

Funnily enough, the *only* feature I needed was ids on headings.


My preferred method of adding ids to headings is to use
*...@id=value}*syntax. For example…

introducti...@id=intro}
===

becomes…

Introduction

I'm using Python-Markdown.
I'm not sure whether other implementations support this syntax. It's worth a
try, though!

David


On 8 December 2010 05:32, Mike Doherty  wrote:

> On 10-12-07 01:07 PM, Dr. Drang wrote:
> > Recall that the OP is using MultiMarkdown, which has more wedged-in
> > features than you can count. One more wouldn't even be noticed.
>
> Funnily enough, the *only* feature I needed was ids on headings.
>
> Well, I'll look at post-processing, as it seems to be the best way to
> accomplish this.
>
> Thanks for your suggestions,
> -Mike
> ___
> 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

Mango 0.5

[David Chambers]

Hi folks,

Mango 0.5  was released a week ago. It
includes several improvements including support for multiple time zones and
the "magic" video syntax Waylan suggested on this mailing list several
months ago.

Mango  is a blogging application which draws content
from Markdown documents. It's high performance, thanks to
memcached,
and does not require a database. If you'd like to give it a try, check out
the setup guide .

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

Should leading and trailing spaces between backticks be preserved?

[David Chambers]

Hi folks,

Yesterday I raised an issue about inconsistent preservation of
whitespacein
Python-Markdown.

>>> import markdown
>>> md = markdown.Markdown()
>>> md.convert('Added `>>> ` to signify user input.')
u'Added >>> to signify user input.'

According to Waylan, all but one of the Markdown implementations drop the
trailing slash within the backticks. This seems wrong to me. I don't buy the
argument that since default browser behaviour is to ignore this space, the
space is insignificant and can be omitted from the markup generated. This is
akin to arguing that lossy compression of audio files is fine since default
(i.e. iPod/iPhone) headphones are of low quality and make it impossible to
detect the difference between compressed and uncompressed versions.

>From a practical standpoint, it should be possible to apply styling to this
markup to drastically change its appearance. One could, for example, apply
`color` and `background-color` styles to invert the code's colours. In
conjunction with certain `white-space` values this could lead to the
following:

Added >>>  to signify user input.

Given the current implementations, information which is in this case
significant has been lost by the time I get my hands on it.

*How do others feel about updating what is considered to be the correct
behaviour here?* Such a change would be backwards compatible since, as
mentioned, default browser behaviour is to ignore such spaces anyway. In
those rare cases where styling has been applied in order to make this
whitespace significant, the change is a reflection of the output's
(improved) fidelity.

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

Re: Should leading and trailing spaces between backticks be preserved?

[David Chambers]

I don't buy the argument that since default browser behaviour is to ignore
> this space,


> Who makes that argument?   If so, I think they're doing it wrong;  recent
> versions of firefox and safari don't ignore trailing spaces in a code span,
> nor do recent versions of lynx.


I should have been clearer. My experimentation revealed that browsers
respect the trailing space between the code tags but ignore the space
following the closing tag. The end result is one space rather than two. The
inverted example renders like so:

Added >>> to signify user input.

Not quite what we're after.

Well, yes, it might be wrong, but that's how the language works ("one after
> the opening, one before the closing" is what <
> http://daringfireball.net/projects/markdown/syntax#code> says, And it
> gives an example (`` `foo` ``) as well.


John's examples suggest that this stripping should apply only within ``
double-backticked `` contexts. I imagine his intention was to avoid the
leading and trailing spaces in `` `foo` `` (required by the syntax) from
being included in the output. I can't imagine any reason to strip whitespace
in regular ` single-backticked ` contexts.

*Do others agree that stripping should occur only within double-backticked
contexts?* Perhaps we could get John to chime in.

David


On 13 February 2011 11:50, David Parsons  wrote:

>
> On Feb 13, 2011, at 11:28 AM, David Chambers wrote:
>
>  Hi folks,
>>
>> Yesterday I raised an issue about inconsistent preservation of whitespace
>> in Python-Markdown.
>>
>>>>> import markdown
>>>>> md = markdown.Markdown()
>>>>> md.convert('Added `>>> ` to signify user input.')
>>u'Added >>> to signify user input.'
>>
>> According to Waylan, all but one of the Markdown implementations drop the
>> trailing slash within the backticks. This seems wrong to me.
>>
>
>  Well, yes, it might be wrong, but that's how the language
> works ("one after the opening, one before the closing" is what
> <http://daringfireball.net/projects/markdown/syntax#code> says,
>  And it gives an example (`` `foo` ``) as well.
>
>  I don't buy the argument that since default browser behaviour
>> is to ignore this space,
>>
>
>  Who makes that argument?   If so, I think they're doing it
> wrong;  recent versions of firefox and safari don't ignore
> trailing spaces in a code span, nor do recent versions of lynx.
>
> And it's not as if there isn't a simple workaround, either;
> if you want your text to be >>>_ (_ for space, of course)
> there's the inelegant replacement of >>>__, which should see
> the second space stripped off leaving you with the first one
> (the extra-inelegant replacement is >>> , which
> will sail happily through at least one markdown processor.)
>
> -david parsons
>
>
>
>-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: Should leading and trailing spaces between backticks be preserved?

[David Chambers]

http://twitter.com/davidchambers/status/36887395974516736

I'll let you know if John replies. :)


On 13 February 2011 12:31, David Chambers wrote:

> I don't buy the argument that since default browser behaviour is to ignore
>> this space,
>
>
>> Who makes that argument?   If so, I think they're doing it wrong;  recent
>> versions of firefox and safari don't ignore trailing spaces in a code span,
>> nor do recent versions of lynx.
>
>
> I should have been clearer. My experimentation revealed that browsers
> respect the trailing space between the code tags but ignore the space
> following the closing tag. The end result is one space rather than two. The
> inverted example renders like so:
>
> Added >>> to signify user input.
>
> Not quite what we're after.
>
> Well, yes, it might be wrong, but that's how the language works ("one after
>> the opening, one before the closing" is what <
>> http://daringfireball.net/projects/markdown/syntax#code> says, And it
>> gives an example (`` `foo` ``) as well.
>
>
> John's examples suggest that this stripping should apply only within ``
> double-backticked `` contexts. I imagine his intention was to avoid the
> leading and trailing spaces in `` `foo` `` (required by the syntax) from
> being included in the output. I can't imagine any reason to strip whitespace
> in regular ` single-backticked ` contexts.
>
> *Do others agree that stripping should occur only within double-backticked
> contexts?* Perhaps we could get John to chime in.
>
> David
>
>
>
> On 13 February 2011 11:50, David Parsons  wrote:
>
>>
>> On Feb 13, 2011, at 11:28 AM, David Chambers wrote:
>>
>>  Hi folks,
>>>
>>> Yesterday I raised an issue about inconsistent preservation of whitespace
>>> in Python-Markdown.
>>>
>>>>>> import markdown
>>>>>> md = markdown.Markdown()
>>>>>> md.convert('Added `>>> ` to signify user input.')
>>>u'Added >>> to signify user input.'
>>>
>>> According to Waylan, all but one of the Markdown implementations drop the
>>> trailing slash within the backticks. This seems wrong to me.
>>>
>>
>>  Well, yes, it might be wrong, but that's how the language
>> works ("one after the opening, one before the closing" is what
>> <http://daringfireball.net/projects/markdown/syntax#code> says,
>>  And it gives an example (`` `foo` ``) as well.
>>
>>  I don't buy the argument that since default browser behaviour
>>> is to ignore this space,
>>>
>>
>>  Who makes that argument?   If so, I think they're doing it
>> wrong;  recent versions of firefox and safari don't ignore
>> trailing spaces in a code span, nor do recent versions of lynx.
>>
>> And it's not as if there isn't a simple workaround, either;
>> if you want your text to be >>>_ (_ for space, of course)
>> there's the inelegant replacement of >>>__, which should see
>> the second space stripped off leaving you with the first one
>> (the extra-inelegant replacement is >>> , which
>> will sail happily through at least one markdown processor.)
>>
>> -david parsons
>>
>>
>>
>>-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: Should leading and trailing spaces between backticks be preserved?

[David Chambers]

>
> Then what about ` ``foo`` ` ?


Excellent point. That I had not considered. Perhaps what I'm trying to
achieve is simply not possible using pure Markdown.

*Edge cases.* >.<


On 13 February 2011 12:49, Michel Fortin  wrote:

> Le 2011-02-13 à 15:31, David Chambers a écrit :
>
> >> Well, yes, it might be wrong, but that's how the language works ("one
> after
> >> the opening, one before the closing" is what <
> >> http://daringfireball.net/projects/markdown/syntax#code> says, And it
> >> gives an example (`` `foo` ``) as well.
> >
> > John's examples suggest that this stripping should apply only within ``
> > double-backticked `` contexts. I imagine his intention was to avoid the
> > leading and trailing spaces in `` `foo` `` (required by the syntax) from
> > being included in the output. I can't imagine any reason to strip
> whitespace
> > in regular ` single-backticked ` contexts.
>
> Then what about ` ``foo`` ` ?
>
>
> --
> 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
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Video syntax

[David Chambers]

Hi folks,

Sorry to revive an old thread, but I thought I'd mention that Mango—as of an
hour ago—now also translates Vimeo video links to appropriate markup.

See, for example,
http://davidchambers.name/blog/di-fara-pizza-documentary/m/ (strip the "m/"
to see the rendered version).

<http://davidchambers.name/blog/di-fara-pizza-documentary/m/><http://davidchambers.name/blog/di-fara-pizza-documentary/m/><http://davidchambers.name/blog/di-fara-pizza-documentary/m/><http://davidchambers.name/blog/di-fara-pizza-documentary/m/>The
relevant line is `[Di Fara pizza documentary][3]`.

Thanks again, Waylan, for suggesting the use of standard link syntax for
video. It's great to be able to keep Markdown documents free of HTML without
introducing new syntax.

David


On 18 September 2010 14:55, David Chambers wrote:

> Hi David,
>
> The URL you received is not (quite) the one I sent. There was (at my end) a
> space between the URL and "(Markdown)". The correct address is
> http://davidchambers.name/blog/soda-pop-stop/m/.
>
> David
>
>
>
> On 19 September 2010 01:22, David Herren  wrote:
>
>> Don't know about anyone else, but these links are failing at present.
>>
>> On Sep 17, 2010, at 10:18 PM, David Chambers wrote:
>>
>> > To see an example visit
>> > http://davidchambers.name/blog/soda-pop-stop/m/(Markdown).
>> >
>> > Then, strip the "m/" from the URL to see the the HTML version.
>>
>>
>> /david
>>
>> --
>> david herren - shoreham, vt, us na terra solsys orionarm
>>
>> Some people have a mental horizon of radius zero, and call it their point
>> of view. -- David Hilbert
>>
>> ___
>> 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: CodeDown = Markdown as the universal language for program documentation

[David Chambers]

Check out Jeremy Ashkenas 's
docco.
Truly beautiful.

David


On 11 April 2011 13:32, bucephalus org  wrote:

> Hi Sherwood,
>
> Thank you very much for your interest and reply!
>
> On Mon, Apr 11, 2011 at 9:05 PM, Sherwood Botsford 
> wrote:
>
>> Interesting concept, but I think you have it partially reversed.
>>
>> You want  php -> codedown -> web
>>
>> I think it would be better:
>>
>> codedown -> php
>> codedown -> markdown -> web
>>
>
> I am not sure, if I understand what you mean. But I am under the
> impression, that maybe you don't understand what the general idea of
> CodeDown is. There is not separate code called "CodeDown", that could or
> should be translated into PHP or Markdown. There is only the source code of
> a particular given programming language, say PHP.
>
> Consider the following simple script, called `example.php`, comprising the
> following code
>
>  /*
> tripleThis($n) returns the three-fold of the given number $n.
> */
> function tripleThis ($n) {
>   return 3 * $n;
> }
> ?>
>
> This is plain standard PHP, with one comment between /*...*/.
> I can run this through my ElephantMark converter, like so
>
> php elephantmark.php example.php
>
> and that returns an empty HTML document, pretty much like this
>
> 
> 
> 
> 
>
> You can also run the example.php script itself and use the triple()
> function, as usual with PHP!
>
> The thing is, that a little modification of the script (in fact, there are
> three simple syntax rules), turns it into a potential self-documentation of
> the script. But note, that the script as PHP script is totally unchanged!
>
> For example, by turning the ordinary command /*...*/ into what I called a
> Markdown block /*** ... ***/, allows us to apply proper Markdown (as a
> super-set of HTML). And putting the function definition between two lines of
> // // // makes that part a literal block.
> So our modified example.php is now say
>
> 
> /***
> # A nice function
>
> `tripleThis($n)` returns the three-fold of the given number `$n`.
>
> Its implementation is as follows:
> ***/
>
> // // //
> function tripleThis ($n) {
>   return 3 * $n;
> }
> // // //
>
> ?>
>
> If we now run the same command
>
> php elephantmark.php example.php
>
> the output will be a HTML  document
>
> 
> 
> A nice function
> 
>   tripleThis($n) returns the three-fold of the given
> number $n$.
> 
> 
>   Its implementation is as follows:
> 
> function tripleThis($n) {
>   return 3 * $n;
> }
> 
> 
> 
>
> So this is a HTML document generated from the PHP source, which is thus
> both, a PHP script and its own documentation.
> (I left away the intermediate step, that the script is first translated
> into Markdown, and that is then translated into HTML. But the normal user
> will not need this intermediate Markdown step.)
>
>
>
>> One of the weaknesses for most programming is that people postpone writing
>> the documentation.
>>
>> In one of the few programming courses I had, the instructor had us write
>> the user manual first.  THEN write the top level description of the program,
>> including documenting the algorithms.  ONLY then could we write the
>> program.  After we had to correct the previous levels.
>
>
> This is exactly the way I personally use my ElephantMark (or PhpCodeDown)
> all the time! Both the PHP program and its HTML documentation can grow
> gradually and simultaneously, and both have the same single source file!
>
>
>>
>
> There is a lot of merit in this for anything that is too complicated to fit
>> into a single file.
>>
>> In addition this approach requires no changes to markdown.
>>
>> Codedown then only has to recognize a different commenting style for
>> whatever language you are using, which I think would make it quick to write.
>>
>
> I am not sure again, if I understand this last part. But maybe, it only
> makes sense in your interpretation.
>
>
> Thank you again, Sherwood, for your comment.
> I think, for people knowing Markdown, the CodeDown idea is all too simple:
> you just need one, two, or three syntax rules concerning the modification of
> comments in the original programming language. And just that makes it so
> universal and easy.
> But maybe, it is so simple, that it is too difficult for me to explain.
>
> Greetings,
> Thomas
>
>
>
>
>
>
>>
>>
>>
>> On Mon, Apr 11, 2011 at 10:17 AM, bucephalus org > gmail.com> wrote:
>>
>>> Dear Markdown enthusiasts out there!
>>>
>>>
>>> Sure, I don't need to tell you how great an versatile Markdown is for
>>> writing standard documents.
>>> I think, that it would make a really great universal standard as a
>>> programming documentation language, too, and maybe "CodeDown" would be a
>>> good title for this approach.
>>>
>>>
>>> The idea started when I was trying to document some PHP scripts. I nee

Consecutive code blocks

[David Chambers]

Hi folks,

I just wrote some Markdown which featured the following code snippets:

TXJS 2011 Speakers

  Brendan Eich
  Alex Russell
  Douglas Crockford
  Paul Irish


ul {
  list-style: square outside;
  color: #ccc;
}

li>span {
  color: #000;
}

The horrible styling above highlights the trailing whitespace a few lines
from the end.

I would love this to be converted to *two* code blocks rather than one.

I realize that the fenced code extension provided by certain implementations
makes it possible to generate
`foo\n\nbar`, but it'd be
nice to be able to achieve this within including a dozen tildes. :)

Has anyone written a Markdown extension along these lines?

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

Re: Consecutive code blocks

[David Chambers]

>
> > How about putting a dummy html comment in the middle, like:

> >
> Code block

> > One

> > 

> > Code block
> Two

It's good to know that this is a possibility, but that's exactly the sort of
hack I'm eager to avoid. ;)

~~~
foo
~~~
~~~
bar
~~~

Even the above feels a little dirty to me.

David


On 13 April 2011 18:09, David Parsons  wrote:

>
> On Apr 13, 2011, at 5:59 PM, David Chambers wrote:
>
>  Hi folks,
>>
>> I just wrote some Markdown which featured the following code snippets:
>>
>>TXJS 2011 Speakers
>>
>>  Brendan Eich
>>  Alex Russell
>>  Douglas Crockford
>>  Paul Irish
>>
>>
>>ul {
>>  list-style: square outside;
>>  color: #ccc;
>>}
>>
>>li>span {
>>  color: #000;
>>}
>>
>> The horrible styling above highlights the trailing whitespace a few lines
>> from the end.
>>
>> I would love this to be converted to two code blocks rather than one.
>>
>
>
>How about putting a dummy html comment in the middle, like:
>
>Code block
>One
>
>Code block
>Two
>
>
>
> -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: Consecutive code blocks

[David Chambers]

I agree that in most cases it's appropriate to include content between two
code blocks. In certain cases, though, such as here where I'm presenting an
HTML snippet with accompanying CSS, there's no need to do so.

The fact that Markdown uses significant trailing whitespace for line breaks
sets a precedent, and makes doing so elsewhere feel slightly less wrong. :)

I'm planning to write extensions for the Markdown implementations I use. The
Markdown example provided parsed *without* such an extension will result in
a single ``, a totally acceptable fallback.

David


On 15 April 2011 07:30, Dr. Drang  wrote:

> The short answer, in my experience, is no. When I've wanted to do
> something like that on my blog, I've rewritten it so I can put a
> little noncode (e.g., "Therefore," "And," "Later in the file") between
> the two code snippets.
>
> I suspect that a blank, unindented line between blocks doesn't create
> two code sections because it's impossible to visually distinguish
> between a between a blank line in the code and a blank line separating
> two bits of code. The only place where Markdown does something similar
> is with two (or more) spaces at the end of a line generate, a
> construct that can generate inadvertent  tags.
>
> Dr. Drang
> ___
> 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

Showdown

[David Chambers]

Hi folks,

As some of you may be aware, I recently released Hashify.
I mention this here because one of the outcomes I'd love to see from the
project is continued development of
Showdown,
John Fraser's JavaScript port of Markdown.

I plan to add support for extensions found in other implementations. It's a
great time to be developing in JavaScript, and the JavaScript community
deserves a living Markdown implementation.

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

markdown.io

[David Chambers]

Hi folks,

I've just registered markdown.io. I'm not sure exactly what I'll do with it,
but I'd like to create a resource for developers seeking to add Markdown
support to their applications. I expect it'll be a single-page site with
plenty of links to documentation for the many implementations that exist.

Let me know if you have any ideas as to what you'd like to see from an
implementation-agnostic "home" for Markdown.

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

Re: What does Markdown do with HTML comments? Recommendation on Markdown file extension?

[David Chambers]

What you're saying is that Markdown is more of a Perl than a Python. :)

There are other options which provide one and only one way to do a
particular thing, but in my opinion none is as elegant as Markdown.
Rather than view Markdown's flexibility as a design flaw, I'm learning
to embrace it. As with programming, my style changes with time. I like
the fact that this can occur.

Incidentally, Gruber wrote the first Markdown conversion script in
Perl. It's interesting to wonder whether Markdown's syntax would be
stricter if he'd used Python instead.

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

Re: Proposed table specification (long!)

[David Chambers]

Fletcher T. Penney  wrote:

   But I think the biggest issue is the monospace vs proportional
> font problem.  This plagues every proposed table syntax out there (to
> my knowledge) --- tables just aren't going to look right in both font types
> in plain text files.  Proper alignment is a key feature of tables, and it's
> frustrating when this is destroyed by changing the font.


The fact that columns in such tables are not aligned when a proportional
font is used is not pertinent, in my opinion. Even a *jagged* "Markdown"
table does a better job of representing data in a tabular fashion than
HTML's mess of s, s, and s.

David


On 11 May 2011 00:09, Simon Bull  wrote:

> Hello Thomas,
>
> In reply to your comments...
>
> Yes, I have assumed mono-spaced (or equivalent) rendering throughout.
>
> Comparing examples 1.1 and example 2.3.b, yes you are correct.  I need to
> update the description given for 1.1 (the so called "compact form").  The
> compact form (without blank lines or rules between rows) will always result
> in a single table row with multiple lines per row.
>
> However, it would be possible to also specify a "single line per row"
> interpretation if that is a desired feature.
>
> Your comment re: "line breaks" versus "blank lines" is also taken on board.
>
> Thanks for your valuable comments,
>
> Simon
>
>
>
> On Wed, May 11, 2011 at 4:45 PM, Thomas Humiston wrote:
>
>> Notes from a writer who makes occasional light use of Markdown and is not
>> involved in implementations at all (nor especially familiar with other -down
>> table syntaxes):
>>
>> I view my plain-text emails in a proportional font (Verdana). Simon's
>> tables look ragged that way, but readable and not terribly unpleasant.
>>
>> Such decoding of occasional monospace-intended bits is, in my view, a
>> fairly conventional matter in email, and thus congruent with Markdown's
>> inspiration. Perhaps the matter of mono vs. proportional is not such a
>> bugbear after all, at least for small-to-medium tables (and for the rest,
>> there's always HTML).
>>
>> But wait -- Given 2.1.b's handling of empty cells, it seems the proposal
>> still assumes some degree of monospace involvement. Similarly, 3.1.a speaks
>> of omitting a space-denoted column break from "between" two columns, a break
>> that is "between" in a sense (either visual or numeric) that's likely
>> obvious in monospace only.
>>
>> So in the proposal, colspans do depend on character counts, and thus on
>> monospace writing tools (except in tables simple enough for manual
>> counting). Well, I suppose most authors of Markdown texts use such tools
>> anyway.
>>
>> A confusing bit for me: Section 2.3.b leaves me thinking that the compact
>> form is usable only for single-row bodies, and NOT for, say, "three rows and
>> three columns" as indicated in Section 1.1. Also, I'd suggest instructing
>> authors to use "blank lines" as Gruber does instead of "line breaks" (as the
>> latter connotes carriage returns and/or newline characters).
>>
>> - TH
>>
>>
>>
>> Simon Bull wrote:
>>
>>  ~
>>>
>>>
>>>   ---
>>>THE PEOPLE OF MIDDLE-EARTH
>>>   ---
>>>
>>> PeopleHomelandTongue
>>>   ===
>>> Elves Rivendell,  Quenya,
>>>   Mirkwood,   Sindarin,
>>>   Lorien  Nandorin
>>>
>>> Dwarves   Erebor  Khuzdul
>>>
>>> Hobbits   The Shire,  Westron
>>>   Breeland
>>>
>>>
>>> ~
>>>
>>>  ___
>> 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

`time` element syntax

[David Chambers]

Hi folks,

I expect that the response to this post will be "we don't need such a
thing", but humour me for a moment by pretending that in fact we do.

HTML5 added a number of new tags to the mix, but arguably the most
significant is the `time` element. It associates a machine-readable
timestamp with a human-readable string (e.g. `30 May 2011`).

I would love to be able to write something like `[30 May
2011]{2011-05-30T15:00-07:00}`.

`/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d)(?::(\d\d)(?:[.](\d+))?)?([-+]\d\d:\d\d|Z)$/`
could be used to ensure that only valid `datetime` attribute values are
matched. This would avoid false positives and would keep `[foo]{bar}`
available for other functions, potentially.

Are there any reasons not to use `[human]{computer}`? Can anyone suggest a
better syntax?

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

Re: `time` element syntax

[David Chambers]

Hi folks,

Thanks for your input. I'm pleased to have raised this issue for discussion.

Michel Fortin  wrote:

Personally, I think if you're going to write a lot of dates like this the
> best syntax would be to auto-detect "30 May 2011" as a date. But this might
> need to be done at another layer than Markdown since Markdown doesn't know
> about your time zone and the date format might depend on your language and
> locale.


Rob McBroom  wrote:

I don’t have any strong feelings about syntax, but manually entering the
> date in two formats doesn’t seem very DRY. I’d prefer to just type one
> (probably the machine-readable one, as it contains the time) and let the
> toasters do the work of generating the other.


The problem with the approach suggested by Rob and Michel is that it works
for only a subset of cases. A very large subset perhaps, but a subset
nonetheless. The displayed text may be "Christmas Day" or "7pm tomorrow".
While in many cases it may seem a violation of DRY to include both forms,
it's clearly not possible to go translate from "human" to machine in all
cases, nor is it necessarily possible to translate in the other direction.

Waylan Limberg  wrote:

Ok, this looks like it would match a valid date and time, but what about a
> date without time or a time without date? According to the spec, all three
> should be allowed. Have fun building that regex.


I lifted the regular expression from
jQuery.localize<https://bitbucket.org/davidchambers/jquery.localize>which
requires at least date, hours, and minutes. You're right, a few more
optional non-capturing groups are required. :)

Waylan Limberg  wrote:

That said, I'm going to ignore the 'looks like a link' issue for a moment
> and add that I think I would prefer something like a reference syntax with a
> datetime label:


>Some text [30 May 2011] more text.


>[30 May 2011]: datetime: 2011-05-30T15:00-07:00


Heck, Waylan, you've done it again. This is extremely readable and allows
the `pubdate` attribute to be included if desired.

Some text [30 May 2011] more text.

[30 May 2011]: datetime: 2011-05-30T15:00-07:00, pubdate

would become…

30 May 2011


Waylan Limberg  wrote:

Now if you can come up with a clean way to make that look less like a link,
> I might be interested in using it myself. Otherwise, I'll stick to raw html
> here.


Square brackets are simply the right characters for the job. One could
consider them to serve a broader function: wrapping text which relates to
some other data, be it a web page, an image, a timestamp, or something else.

The resemblance to links is actually a *good* thing in my opinion. It allows
readers to guess (correctly) that the there is accompanying data and that
it likely resides after the current paragraph or at the end of the document.

David Parsons  wrote:

 That looks like it would be a good place for a pseudo-protocol:


>[two days ago](time:2011-05-30T15:00-07:00 "May 30th, if you care")


> This would have the advantage of being fairly unambiguous, instead of
> superimposing a magic time string over the existing linkyformat.


This is definitely less ambiguous, but causes the sentence's flow to be
interrupted. Perhaps I've been writing too much JavaScript and CoffeeScript
lately, but overloading existing syntax—as opposed to introducing new
syntax—seems like the right approach to me.

I'm going to go ahead and see if I can implement Waylan's suggestion in
Showdown <http://davidchambers.bitbucket.org/showdown/>.

David


On 2 June 2011 11:31, Michel Fortin  wrote:

> Le 2011-06-02 à 5:08, David Chambers a écrit :
>
> > Hi folks,
> >
> > I expect that the response to this post will be "we don't need such a
> > thing", but humour me for a moment by pretending that in fact we do.
> >
> > HTML5 added a number of new tags to the mix, but arguably the most
> > significant is the `time` element. It associates a machine-readable
> > timestamp with a human-readable string (e.g. ` > datetime="2011-05-30T15:00-07:00">30 May 2011`).
> >
> > I would love to be able to write something like `[30 May
> > 2011]{2011-05-30T15:00-07:00}`.
> >
> >
> `/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d)(?::(\d\d)(?:[.](\d+))?)?([-+]\d\d:\d\d|Z)$/`
> > could be used to ensure that only valid `datetime` attribute values are
> > matched. This would avoid false positives and would keep `[foo]{bar}`
> > available for other functions, potentially.
> >
> > Are there any reasons not to use `[human]{computer}`? Can anyone suggest
> a
> > better syntax?
>
> Personally, I think if you're going to write a lot of dates like this the
> best syntax would be t

Re: `time` element syntax

[David Chambers]

Michel Fortin  wrote:

I'd tend to go for something even simpler:


>Some text 30 May 2011 more text.



   *[30 May 2011]: 2011-05-30 15:00 -07:00


> Basically, why do we need to force brackets in the text at all? Also, why
> force the writer to use 'T' as a time separator and strictly follow to the
> rules of HTML date syntax? It's much more readable without the 'T'.
> Reformatting it to HTML's liking should be pretty trivial.


I *love* this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation
syntax (I'll read up on it); building upon an established convention sounds
very sensible to me.

Michel Fortin  wrote:

> The resemblance to links is actually a *good* thing in my opinion. It
> allows
> > readers to guess (correctly) that the there is accompanying data and that
> > it likely resides after the current paragraph or at the end of the
> document.


> I disagree. Someone reading the HTML output in the browser is unlikely to
> notice there's a date/time element here or there on the page with a
> computer-readable date. And even if you made date time elements flashing
> red, what would be the point?


I was referring to the resemblance to links in the Markdown itself. I agree
that the existence of a machine-readable version of a date is likely to be
of little interest to readers of the *rendered* document.

David Parsons  wrote:

These are *exactly* the same thing, except for the trivial difference of
> using `datetime:` vs `time:` as the name for the pseudo-protocol.   I fail
> to see how using `time:` interrupts the sentence flow when `datetime:` does
> not.


I was unclear. I have no strong feelings as to `datetime:` versus `time:`.
What I like about the suggestion Waylan put forward is that it allows the
machine-readable timestamp to be placed at the end of the document, to avoid
having it interrupt sentence flow. Based on your response it appears that I
failed to draw to consider…

[two days ago](time:2011-05-30T15:00-07:00 "May 30th, if you care")

to be a placeholder for…

[two days ago](time:2011-05-30T15:00-07:00 "May 30th, if you care")

*or…*

[two days ago][1]

[1]: time:2011-05-30T15:00-07:00 "May 30th, if you care"

in which case I like this syntax also.

I am most enamoured with Michel's proposed bracket-free syntax. What do
others think of it?

David


On 5 June 2011 16:35, David Parsons  wrote:

>
>
> So, you like:
>
>
>  Waylan Limberg  wrote:
>>
>> That said, I'm going to ignore the 'looks like a link' issue for a moment
>> and add that I think I would prefer something like a reference syntax with a
>> datetime label:
>>   Some text [30 May 2011] more text.
>>   [30 May 2011]: datetime: 2011-05-30T15:00-07:00
>>
>> Heck, Waylan, you've done it again. This is extremely readable and allows
>> the `pubdate` attribute to be included if desired.
>>
>
> But you don't like:
>
>
>  David Parsons  wrote:
>>
>>That looks like it would be a good place for a pseudo-protocol:
>>   [two days ago](time:2011-05-30T15:00-07:00 "May 30th, if you care")
>>This would have the advantage of being fairly unambiguous, instead of
>> superimposing a magic time string over the existing linkyformat.
>>
>> This is definitely less ambiguous, but causes the sentence's flow to be
>> interrupted.
>>
>
>
>These are *exactly* the same thing, except for the
> trivial difference of using `datetime:` vs `time:` as
> the name for the pseudo-protocol.   I fail to see how
> using `time:` interrupts the sentence flow when
> `datetime:` does not.
>
>
>   -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: `time` element syntax

[David Chambers]

Three people on markdown-discuss in agreement? Must be a new record. :)

Thanks for weighing in, Waylan.

David


On 5 June 2011 18:57, Waylan Limberg  wrote:

> On Sun, Jun 5, 2011 at 8:35 PM, David Chambers
>  wrote:
> > Michel Fortin  wrote:
> >>
> >> I'd tend to go for something even simpler:
> >>
> >>Some text 30 May 2011 more text.
> >>
> >>
> >>
> >>*[30 May 2011]: 2011-05-30 15:00 -07:00
> >>
> >> Basically, why do we need to force brackets in the text at all? Also,
> why
> >> force the writer to use 'T' as a time separator and strictly follow to
> the
> >> rules of HTML date syntax? It's much more readable without the 'T'.
> >> Reformatting it to HTML's liking should be pretty trivial.
> >
> > I love this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation
> > syntax (I'll read up on it); building upon an established convention
> sounds
> > very sensible to me.
>
> I'll have to say I like this as well. It hadn't occurred to me that
> like the abbreviation syntax, we don't need to mark up the text at
> all.
>
> Regarding the time v. datetime, I picked datetime because that is the
> name of the html attribute the same value would be assigned to. But
> time is certainly shorter. Maybe you won't need either as Michel
> suggests.
>
> --
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> 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: Data loss issue: Adjacent List Types

[David Chambers]

I agree with Lasar that such cases arise infrequently. I do support such a
change in theory, though, but I'm not sure how difficult this would be to
implement given the fact that double line breaks can be used to have list
items wrapped in `p` tags.

Alan Hogan  wrote:

After all, what end-user would *rely* on this feature to munge their list
> types?


Good point.

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

Re: Data loss issue: Adjacent List Types

[David Chambers]

Alan Hogan  wrote:

Given that I still struggle to see a downside to making my proposed change,
> I’m really hoping we can achieve a rough consensus here.


+1

David


On 6 June 2011 11:26, Alan Hogan  wrote:

> Quoth _Lasar:
>
> while I agree that this is technically an issue, I don't think it
> is an often seen issue in actual human-written text. Markdown is
> plain text formatted by and for humans. I don't think there are
> many cases where you would want to put two lists after each other
> without an introduction of sorts.
>
> I must of course agree that it is not an exceedingly common case, or a
> terribly sensible decision to make.
>
> That said:
>
>
>- Consider a student quickly taking notes, or a liveblogger publishing
>quickly. They may not have time to write an intro for each list, or realize
>that they skipped it…
>- I personally have experienced this issue, so it does happen.
>- Even if a small fraction of users run into this issue — half a
>percent, say — if I am providing a service to two hundred thousand of users
>(and I do), that’s a thousand people affected.
>
>
>
> And on a side note: Gruber notes in the markdown spec that the
> actual numbers used in a numbered list are ignored. So data loss
> is already occuring here.
>
>
> Now that is true.
>
> However:
>
>
>- Existing data loss doesn’t mean we should be okay with more data
>loss.
>- The numbers couldn’t really be always matched in output given how
>HTML works, anyway…
>- I personally made a mistake by starting a paragraph with “1999.”
>today, so this too can cause problems. (At least it’s part of the Markdown
>spec though.)
>- I am personally disappointed that the `start` attribute (?) isn’t
>used, based off the first number in the list; this would also help catch
>mistakes.
>
>
> Given that I still struggle to see a downside to making my proposed change,
> I’m really hoping we can achieve a rough consensus here.
>
>
> ___
> 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: Data loss issue: Adjacent List Types

[David Chambers]

John MacFarlane  wrote:

I also think that the following should be interpreted as two different
> unordered lists (that is, the change of bullet character should be
> significant):
>
> ~~
> * one
> * two
>
> - new
> - list
> ~~


+1 to this, too.

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

Re: Data loss issue: Adjacent List Types

[David Chambers]

David Parsons  wrote:

John Gruber might have some opinions about this; I'd certainly be more
> attentive about list merging if the reference dingus changed to split them.


Every member of this group writes a lot of Markdown, and has its best
interests at heart. In addition, this list contains several implementors and
dozens of people who have created extensions for Markdown or integrated it
into their applications. John Gruber continues use Markdown on a daily
basis; quite possibly he remains the most prolific author of Markdown
documents (based on the length of some of his pieces). John's opinions will
always be held in high regard when he chooses to share them.

That said, if John were to consider Markdown "complete", should we stop
thinking of ways in which it could be improved? I'm grateful on an almost
daily basis to those who answer "no". These individuals have made it
possible for me to include definition lists, heading ids, and metadata,
without resorting to HTML tags. This, to me, is a triumph in the true spirit
of John's original design.

Should the fact that John does not often call upon definition lists in his
own writing mean that syntax for this structure has no place in Markdown? In
my view, no.

I don't think it's realistic to expect John to remain essentially the sole
contributor to this project. If John remains the source of truth, things
will remain as they are today, with each implementation providing its own
set of extensions, solving the same problems but sometimes via incompatible
syntaxes.

If the community (by which I mean the members of this list) agrees that
syntax should exist for a certain HTML element or structure (definition
lists, for example), I'd love to see a collaborative effort to standardize
the syntax. This would involve highlighting the syntaxes currently in use
(both as Markdown extensions and as parts of other plaintext formatting
languages), to see whether a convention is already firmly established.
Discussion of the various options could then commence with the goal of
agreeing upon a standard syntax for all implementations to adopt.

The problem is, though, that not everyone on this list agrees that
standardizing Markdown's extensions is desirable. I've created a repository
on GitHub — https://github.com/markdown/discussion — whose issue tracker
could be used by those of us interested in such discussion. I've just
created a thread  for
further discussion of possible `time` element syntaxes, and I'll start
another once I've had time to research existing definition list extensions.

David


On 6 June 2011 19:05, David Parsons  wrote:

>
> On Jun 6, 2011, at 6:50 PM, Seumas Mac Uilleachan wrote:
>
>  On 06/06/11 02:26 PM, Alan Hogan wrote:
>>
>>>
>>> Given that I still struggle to see a downside to making my proposed
>>> change, I’m really hoping we can achieve a rough consensus here.
>>>
>>
>  How often do people complain?   Once every 5 years?
> The only complaint I've ever seen about list merging was
> when I first wrote discount and got complaints that the
> lists *weren't* being merged.
>
>  Compare that to the almost nonstop complaining about
> middle-of-word emphasis, which seems to have bitten
> everyone who seriously uses markdown.
>
>  John Gruber might have some opinions about this;
> I'd certainly be more attentive about list merging
> if the reference dingus changed to split them.
>
>
>
>  I also remember copy-pasting some info from the web that had a sentence
>> starting with 1999. (or similar) as there was a hard return in the line
>> before it. It took me ages to figure out where that list was coming from in
>> the middle of the paragraph. Eventually found the hard return and deleted
>> it.
>>
>
>  That's a different issue, though, which has bitten
> enough people so that it's actually mentioned in the
> syntax document on daring fireball.
>
>
>   -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: `time` element syntax

[David Chambers]

g/OjpbMC01XVxkKD86XC5cZCspPyk/ICAgIyBzZWNvbmRzPwogICAgICAgICkKICAgICAgICBceDIwCiAgICAgICAgKD86ICAgICAgICAgICAgICAgICAgICAgICAgICMgdGltZSB6b25lIG9mZnNldAogICAgICAgICAgKEdNVHxVVEMpICAgICAgICAgICAgICAgICAjIFs0XSBVVEMKICAgICAgICB8IChbKy1dKSAgICAgICAgICAgICAgICAgICAgIyBbNV0gc2lnbgogICAgICAgICAgKCg/OjB8MSk/XGR8MlswLTNdKSAgICAgICAjIFs2XSBob3VycwogICAgICAgICAgKD86OihbMC01XVxkKSk/ICAgICAgICAgICAjIFs3XSBtaW51dGVzPwogICAgICAgICkKICAgICAgKT8KICAgICAgKFx4MjBwdWJkYXRlKT8gICAgICAgICAgICAgICAgIyBbOF0gcHViZGF0ZT8KICAgICAgW1x4MjBcdF0qICQKICAgIC8vL2dtCg==?mode:presentation>
.

David


On 5 June 2011 19:04, David Chambers  wrote:

> Three people on markdown-discuss in agreement? Must be a new record. :)
>
> Thanks for weighing in, Waylan.
>
> David
>
>
>
> On 5 June 2011 18:57, Waylan Limberg  wrote:
>
>> On Sun, Jun 5, 2011 at 8:35 PM, David Chambers
>>  wrote:
>> > Michel Fortin  wrote:
>> >>
>> >> I'd tend to go for something even simpler:
>> >>
>> >>Some text 30 May 2011 more text.
>> >>
>> >>
>> >>
>> >>*[30 May 2011]: 2011-05-30 15:00 -07:00
>> >>
>> >> Basically, why do we need to force brackets in the text at all? Also,
>> why
>> >> force the writer to use 'T' as a time separator and strictly follow to
>> the
>> >> rules of HTML date syntax? It's much more readable without the 'T'.
>> >> Reformatting it to HTML's liking should be pretty trivial.
>> >
>> > I love this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation
>> > syntax (I'll read up on it); building upon an established convention
>> sounds
>> > very sensible to me.
>>
>> I'll have to say I like this as well. It hadn't occurred to me that
>> like the abbreviation syntax, we don't need to mark up the text at
>> all.
>>
>> Regarding the time v. datetime, I picked datetime because that is the
>> name of the html attribute the same value would be assigned to. But
>> time is certainly shorter. Maybe you won't need either as Michel
>> suggests.
>>
>> --
>> 
>> \X/ /-\ `/ |_ /-\ |\|
>> Waylan Limberg
>> ___
>> 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: `time` element syntax

[David Chambers]

Here's an updated link: "datetimes"
extension.
This URL is identical to the previous but for the fact that it disables
syntax highlighting (which makes this particular document more pleasant to
read).

David


On 26 June 2011 11:38,  wrote:

> waylan said:
> >   It hadn't occurred to me that
> >   like the abbreviation syntax,
> >   we don't need to mark up the text at all.
>
> you're starting to get zen.  starting to get zen.
>
> the lightest markup of all is zero markup.
>
> -bowerbird
>
> ___
> 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: writing tools that use light-markup

[David Chambers]

>
> Not sure which “extras” are available in Showdown (if any).


My Showdown fork is now significantly different from John Fraser's version.
It's extensible, and so far I've created two extensions.

If you're interested, have a look at the annotated source code:

   - showdown.coffee <http://davidchambers.bitbucket.org/showdown/>
   - 
abbreviations.coffee<http://davidchambers.bitbucket.org/showdown/abbreviations/>
   - datetimes.coffee<http://davidchambers.bitbucket.org/showdown/datetimes/>

David


On 8 July 2011 05:57, Rob McBroom  wrote:

> On Jul 7, 2011, at 4:35 PM, Alan Hogan wrote:
>
> > Anyone know of other helpful interactive Markdown editors?
>
>
> http://hashify.me/ from David Chambers has some of this. Not sure which
> “extras” are available in Showdown (if any).
>
> --
> Rob McBroom
> <http://www.skurfer.com/>
>
> ___
> 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: php-markdown-extra-extended - my humble attempt at extending php-markdown

[David Chambers]

Albert Skye  wrote:

   This paragraph has an attribute list attached by reference.


>{ref}


>[ref]: #id .class name=value


This strikes me as an elegant solution to the problem, askye. Does anyone
know of an extension that uses this syntax?

David


On 14 July 2011 03:53, Michel Fortin  wrote:

> Le 2011-07-14 à 6:01, Albert Skye a écrit :
>
> >> [1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
> >
> > I don't understand why the leading colon should be present.
> >
> > In any case, it seems reasonable to:
> >
> > - enclose attributes in braces (to indicate text meant for
> authors/editors rather than readers)
> > - append attributes to elements (where they are likely to be somewhat
> less hideous)
> > - use whitespace before the attribute lists for block elements (up to one
> blank line)
> > - use conventional syntax
> >
> >   This paragraph has an attribute list attached by reference.
> >
> >   {ref}
> >
> >   [ref]: #id .class name=value
> >
> > Am I missing something?
>
> That's actually what Jonh Gruber proposed a while back when he was still
> participating on this list. In his view, only {ref} was allowed, you
> couldn't specify attributes directly inline. It's not that easy to find the
> old emails, but I clearly remember it.
>
>
> --
> 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
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Universal syntax for Markdown

[David Chambers]

Every other language I use on a daily basis (Python, JavaScript,
CoffeeScript, HTML, CSS, and heck, even English) is evolving. CoffeeScript *
1.1.2*, ECMAScript *5*, HTML*5*, CSS*3*… I'm seeing a pattern. ;)

I don't understand why a significant number of people in this community feel
that Markdown is a special case and that each of us should be responsible
for extending it as we see fit. This is similar to the state of JavaScript
in 2005 or so. Those using JavaScript at the time demanded convenience
methods such as `Array::each` and `String::trim` so extended these global
objects themselves (or used Prototype). The problem with this approach is
that one person's `Array::each` is not necessary interoperable with
another's. I'm *much* happier with the state of JavaScript today, now that
the language is incorporating the things we've been doing for years.

David


On 10 August 2011 12:14, Alan Hogan  wrote:

>
> > Hi,
> >
> > because of the great editor "Writer" from Information Architects I've
> > learned about Markdown and I love it. But it's very confusing, that
> > there are so many standards with different features: classical
> > Markdown, Markdown Extra, MultiMarkdown. I think for most users and
> > the spreading of Markdown it would be nice, to have only one syntax.
> >
> > And this universal syntax should have the additions of MultiMarkdown:
> > footnotes, tables, definition lists, citation, metadata (author,
> > title, date), and so on... Because I think many people would like to
> > have these additional functions in Markdown. And who doesn't need
> > these additional functions, simply doesn't use them.
> >
> > I think, one universal Markdown-syntax with the additional
> > possibilities of MultiMarkdown would be less confusing for consumers
> > and would help to spread Markdown in more apps and to more users.
> > Because it's really great!
>
> Flo, I completely agree with you. It's absurd.
>
> There are two steps to evolution: Mutation and natural selection. With
> Markdown we see more mutation than selection, though MultiMarkdown and PHP
> Markdown Extra do seem to be "selected" more than other mutations.
>
> There are those of us in the Markdown community who hope for some sort of
> official, largely-universial "version 2" of some sort (whatever it's
> called). Unfortunately this desire is far from universal.
>
> Alan
> ___
> 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: Universal syntax for Markdown

[David Chambers]

Great post, John. It's full of interesting thoughts so may take some time to 
digest.

You mentioned Babelmark, which caught my attention. I was not aware of its 
existence, and the discovery excited me greatly. A service of this nature will 
be invaluable for those who undertake the challenge of documenting the 
differences that exist between the many implementations.

The idea that translations could be retrieved via API calls is appealing. It 
would distribute the significant maintenance burden of keeping current the 
source of the various "Markdowns" and their respective dependencies.

Perhaps Babelmark could switch to making API calls to obtain translations as 
developers make endpoints available. What are your thoughts, Michel? I'd love 
to contribute to this effort if you consider it worthwhile.

David


On Aug 13, 2011, at 3:00 PM, John MacFarlane wrote:

> I'll chime in too. In developing pandoc, lunamark, and peg-markdown, I've
> thought a lot about markdown extensions, and also about how to resolve some of
> the ambiguities in the markdown syntax description.
> 
> I agree that it would be good if the various implementations could
> converge as much as possible on these things. In some cases, they have
> converged: I think most implementations do footnotes the same way, for
> example, and as a result of a discussion on this list, PHP markdown extra
> and pandoc have the same syntax for fenced code blocks. In other cases, they
> haven't converged, even after discussion. Some of the divergences are pretty
> basic -- e.g. whether nested lists have to be indented by 4 spaces.
> 
> Of course, going forward, implementors have to worry about backwards
> compatibility.  I don't want to make changes that are going to break
> old pandoc documents.  On the other hand, there's no reason why an
> implementation has to accept just one syntax for (say) definition
> lists.  So if we could agree on a standard syntax that diverged from
> pandoc's old syntax, I might be able to modify pandoc to accept them
> both.
> 
> I can think of two tools that would help a lot in discussions about
> extensions and edge cases:
> 
> *  An updated version of [babelmark](http://babelmark.bobtfish.net/),
>   which allows you to compare the output of many implementations on the same
>   input. This was really a useful tool in its time -- any chance it could be
>   updated? The version of pandoc there, for example, is about three years
>   old. [I know it's a burden to keep versions of so many implementations
>   up to date. Perhaps each maintainer could set up a web app that returns
>   output and metadata (version number, author, website) for a single
>   implementation. There could be an API key so that only the main babelmark
>   site could use these apps. babelmark could then just send out a bunch of
>   HTTP queries and display the output.  It wouldn't even need its own server.]
> 
> *  A wiki with a page for each syntax feature or extension, allowing
>   comparison of different versions and discussion of pros and cons,
>   with links to user's guides etc.
> 
> *  A test suite articulated into many very small tests, each testing
>   something very specific. We could try to separate these into "agreed" and
>   "disputed."  There are many tests that extend the standard Markdown
>   test suite that would be agreed on by virtually everyone.
>   Michel Fortin's MDTest is a major step in this direction.
>   I have a nice little test-runner that allows each test to be in
>   a single file, with  input and expected output. This makes it easy
>   to add little tests.
> 
> A few more thoughts:
> 
> 1.  Many people have mentioned "rule #1" - markdown should look natural and
> readable just by itself. I strongly agree. In my own tinkerings, I've also
> insisted on another principle, which Fletcher also articulated, but which I
> think would not be accepted by everyone on this list:
> 
>  Format-independence:  Markdown is not just for writing HTML.
> 
> I've seen people on this list say, "why do you need extension X, when you
> can just include raw HTML?"  To which I reply: "Because I want to be
> able to convert my document to LaTeX, where the raw HTML won't do much good."
> It's true that John Gruber presented markdown primarily as a readable shortcut
> to HTML. But I don't see why we should keep thinking about it this way, when
> tools like pandoc and multimarkdown can easily convert markdown to a variety
> of formats. Indeed, one of the main reasons I write in markdown whenever I
> can is that I'm not tied to a single output format. I can have a canonical
> document that can be converted reliably to just about any text format.
> 
> 2.  We really need to clarify the rules for indented lists.  As I've
> argued before on this list, the markdown documentation at least strongly
> implies that sublists need to be indented by four spaces, but many
> implementations (including Markdown.pl) don't insist on this.
> 
> 3.  I think most people agre

Re: Universal syntax for Markdown

[David Chambers]

First let me say that this thread has me excited. There's a great deal of 
constructive discussion, and a surprising number of "I agree" replies.

I'll add my two cents on the particulars that have been discussed herein.

Metadata

Just about every Markdown document I create includes metadata (for date, time, 
and time zone, and sometimes tags). I couldn't live without it, but as a user 
it doesn't matter to me whether these data are processed by the Markdown 
library itself or, as Waylan suggested, by "a separate […] library (like YAML) 
which reads and removes the metadata".

I think Alan's suggestion that Markdown should define syntax for a metadata 
section (while ignoring the contents of such sections) is an excellent one.

Definition lists

The fact that including more than one definition for a given term is an 
uncommon requirement should not preclude such use cases from being 
accommodated. Rather than thinking in terms of the "rendered" content (be it 
HTML, PDF, or some other format) we should first think in terms of what our 
content means and how best to express that meaning in a structured fashion.

Definition lists are a good case in point. What is a definition? Text that 
explains the meaning of or describes some thing. There therefore exists some 
relationship between the definition and the thing it defines. Also, there may 
be several ways to describe one thing. What is the relationship between various 
definitions for a particular thing? Are they equally important? Are they 
sequential? Can they be grouped in some way? Can one description apply to more 
than one thing?

Only once we have considered the meaning and structure of our content in the 
abstract should we consider how best to express it in Markdown and how best to 
translate it to each of the various publication formats.

Should changing from ordered to bulleted list markers start a new list?

Yes.

Table syntax

As has been stated, there's more diversity in the table syntax supported by the 
various extensions than exists for most other language additions. This 
indicates that tables will likely be much harder to "solve" than definition 
lists or footnotes. That's fine. This needn't all happen at once. Here's how I 
imagine the transition to "Markdown 2" might work:
Several people write documents (for lack of a better term). Each of these would 
define how a particular group of edge cases should be handled, or would propose 
syntax definitions for a language addition that exists as a popular extension. 
These brave souls would analyze differences between the various implementations 
and would present the pros and cons of each (in terms of readability, 
writeability, and implementation complexity) and may follow this with an actual 
proposal.
These documents are discussed at length on this list, and amendments are made.
The two or three least contentious proposals are further hammered out and 
eventually — say, 18 to 36 months from now — become part of the "Markdown 2" 
specification.
Library maintainers decide how best to react to these additions. Some will 
decide to remain a pure Markdown (1) library, which is fine. Others will decide 
to maintain full backwards compatibility with Markdown (1) but will update the 
affected extensions to accept the standardized syntax (exclusively, or in 
addition to the existing syntaxes). As Alan has suggested, new libraries may 
emerge which fully support the additions made in "Markdown 2".
Repeat steps 1–4 indefinitely.
The above is not much different from what happens currently. Furthermore, one 
can see how existing libraries could adopt "Markdown 2" without breaking 
backwards compatibility in most cases. Features which currently only exist as 
extensions could continue to exist as extensions in many implementations. As 
for edge cases which are clarified in "Markdown 2", well, they are by 
definition unreliable in Markdown as it exists today.

David


On Aug 15, 2011, at 6:51 PM, Alan J. Hogan wrote:

> On document meta:
> 
> On Aug 13, 2011, at 7:14 PM, Waylan Limberg  wrote:
> 
>> Interestingly, after having this feature for a few years, I would
>> instead prefer a separate library (like say YAML) which  reads and
>> removes the metadata before passing the document on to markdown. In
>> fact, the metadata could even alter some of the arguments passed to
>> markdown, or perhaps skip calling markdown at all (basically like
>> Jekyll - used by Github Pages). To me this is much more flexible and
>> doesn't require markdown to define a metadata syntax at all. Just let
>> YAML (or whatever spec is chosen) determine the syntax and we
>> automatically get the benefits of that spec's well developed data
>> structure.
> 
> Hyde (Jekyll in Python) does this too and it really feels nice. The ability 
> to embed complex arbitrary data in some documents' metadata was very handy 
> (when used in conjunction with the theme and other non-markdown languages).
> 
> Quoth Michel:
> 
>> I'd certainly not

Re: Universal syntax for Markdown

[David Chambers]

Waylan Limberg  wrote:

Just an FYI, but the section separator that Alan mentioned is actually part
> of YAML. In fact, IIRC without it the YAML parser would consider it an
> invalid document. I guess the point is that what marks the meta-data could
> be dependent on what format is used for meta-data. That might be hard to
> define in a Markdown spec if we leave it open for any meta-data format.


The idea I had in mind is that if Markdown were to define a syntax for a
metadata section, Markdown parsers could ignore such sections. That way, a
given document with metadata wouldn't *require* a particular preprocessor in
order to render sensibly.

Sherwood Botsford  wrote:

I would propose that all versions of MD support three flags -quirks and
>  -standard -strict.


Excellent. I don't think that all versions would need to support all three –
a new implementation needn't provide a "quirks mode", for example.

I suggest tweaking the flags slightly:

*--quirks*
Backwards-compatibility mode for the implementation in question. In quirks
mode, two implementations may give different output for a given input.

*--standard*
Full support for all current language features as defined by the
then-current specification. For any given input, every implementation should
produce the same output, although the output may differ from that produced
in quirks mode.

*--quirks --extensions ext1 ext2 … extN*
Backwards-compatibility mode plus backwards-compatible versions of the
required extensions.

*--standard --extensions ext1 ext2 ... extN*
Full support for all current language features as defined by the
then-current specification, plus extensions that conform to the syntax which
is to be included in the spec at some point in the future. Making language
extensions opt-in initially would make it possible to test a language
extension in the wild before its behaviour is set in stone.

For example, one might translate a particular document using --standard
--extensions footnotes until, at some point in the future, footnotes become
part of the specification. One could then switch to simply using --standard.

David


On 16 August 2011 08:50, Waylan Limberg  wrote:

> On Tue, Aug 16, 2011 at 1:07 AM, David Chambers
>  wrote:
> > First let me say that this thread has me excited. There's a great deal of
> > constructive discussion, and a surprising number of "I agree" replies.
> > I'll add my two cents on the particulars that have been discussed herein.
> > Metadata
> > Just about every Markdown document I create includes metadata (for date,
> > time, and time zone, and sometimes tags). I couldn't live without it, but
> as
> > a user it doesn't matter to me whether these data are processed by the
> > Markdown library itself or, as Waylan suggested, by "a separate […]
> library
> > (like YAML) which reads and removes the metadata".
> > I think Alan's suggestion that Markdown should define syntax for a
> metadata
> > section (while ignoring the contents of such sections) is an excellent
> one.
>
> Just an FYI, but the section separator that Alan mentioned is actually
> part of YAML. In fact, IIRC without it the YAML parser would consider
> it an invalid document. I guess the point is that what marks the
> meta-data could be dependent on what format is used for meta-data.
> That might be hard to define in a Markdown spec if we leave it open
> for any meta-data format.
>
> > Definition lists
> > The fact that including more than one definition for a given term is an
> > uncommon requirement should not preclude such use cases from being
> > accommodated. Rather than thinking in terms of the "rendered" content (be
> it
> > HTML, PDF, or some other format) we should first think in terms of what
> our
> > content means and how best to express that meaning in a structured
> fashion.
> > Definition lists are a good case in point. What is a definition? Text
> that
> > explains the meaning of or describes some thing. There therefore exists
> some
> > relationship between the definition and the thing it defines. Also, there
> > may be several ways to describe one thing. What is the relationship
> between
> > various definitions for a particular thing? Are they equally important?
> Are
> > they sequential? Can they be grouped in some way? Can one description
> apply
> > to more than one thing?
>
> Valid questions. Interestingly, the HTML5 spec answers some of this.
> In fact, the HTML5 spec [1] calls `` a "description list" which
> expands beyond definitions. It states: "Name-value groups may be terms
> and definitions, metadata topics and values, questions and answers, or
> any other groups of

Re: Metadata syntax (was Universal syntax for Markdown)

[David Chambers]

It is true that certain metadata (author and date, to provide two examples)
are used far more frequently than return addresses or URIs for graphical
signatures. That said, it would be foolish to try to imagine every way in
which metadata might be used, nor do I see much value in doing so.

If Markdown is to process metadata, the syntax should support arbitrary
key–value pairs.

For example:

author: Jesper Nøhr
date: 17 August 2011
tags: lol, omg, lulz

Formatted differently:

author: Jesper Nøhr
date: 17 August 2011
tag: lol
tag: omg
tag: lulz

If — again, if — Markdown is to be charged with parsing metadata, my opinion
is that it's role should be limited to returning a dictionary-like metadata
object (in addition to the HTML string generated from the remainder of the
document's contents).

For the first example:

{"date": "17 August 2011", "tags": "lol, omg, lulz", "author": "Jesper
Nøhr"}

For the second example:

{"date": "17 August 2011", "author": "Jesper Nøhr", "tag": ["lol",
"omg", "lulz"]}

In my opinion, Markdown should *not* be responsible for any of the
following:

   - splitting lists (note that "lol, omg, lulz" is a string in the first
   example)
   - converting date strings into date objects
   - any other manipulation of values

In other words, every value should be either a string, or an ordered,
list-like object containing two or more strings (in the case of a repeated
key).

In addition to converting strings into appropriate objects, applications
making use of Markdown's metadata feature would also be responsible for
handling the fact that the value for a particular key may be a string for
one document and a list of strings for another.

Fletcher touched on another question that should be discussed: should
multiline values be accommodated and if so, how?

I think it'd be great to support multiline strings. I imagine the formatting
looking something like this:

author:
  Jesper Nøhr
date:
  17 August 2011
lol:
  Irony keffiyeh pitchfork, mustache letterpress tofu cred twee scenester
  thundercats gluten-free yr chambray sartorial stumptown. Homo cosby
sweater
  gentrify banh mi letterpress, vinyl beard hoodie terry richardson. Art
party
  whatever banksy, readymade skateboard you probably haven't heard of them
  tumblr tattooed PBR letterpress photo booth carles vegan organic.
omg:
  VHS carles photo booth food truck synth craft beer, wes anderson tofu
banksy
  fanny pack stumptown.

This strikes me as being in the spirit of Markdown, as it's how one might
structure this content if one were to produce it on a typewriter.

I'm interested to hear people's thoughts on multiline values and on the
unfancy approach to metadata parsing that I (currently) favour.

David


On 17 August 2011 15:17, M Harris  wrote:

> So, hi all. First time commenting on the list.
>
> I personally think having tags (whether of type "author:" or type "by")
> is useful for two reasons.
> One: It allows multiple tags to be entered. Two, it clears up the
> potential problem listed by Fletcher regarding tags.
>
> by Christoph Freitag
> Affiliation: XYZ
> by Fletcher T. Penney
> Affiliation: ABC
> tags: Markdown, Standardization, MMD, Metadata
> desc: An interesting discussion of how metadata could be included
> usefully in Markdown, whilst being readable etc.
>
>
> Regarding the localisation problem then, I thought that this was a
> solved problem when it came to computing? (At least in the cases of the
> major world languages.) A parser could have a table of equivalent words,
> so in English "by", en français "de" (pardon my French*).
>
> * By which I mean, I'm not sure that's correct, because I'm only a
> learner.
>
> > From: Christoph Freitag 
> > Fletcher, sorry, but personally -- despite loving MMD (and even having
> used MMD CMS for a diary) -- I have never liked the way MMD handles
> metadata. Partly this is because, not being a native English speaker, I
> dislike English meta descriptors. A localization could resolve this -- but I
> still think it looks ugly. However, do you actually need descriptors at all?
> I doubt it:
> >
> > *   The title could be anything "at the start" of the document. Blosxom
> is a good example. Anything up to the first blank line is the title.
> > *   After that, anything between the first blank line and the second
> blank line would be treated as additional metadata.
> > *   Instead of the "Author:" descriptor, explicitely stated, it should
> suffice to write "by". What follows is the name of the author. (Localization
> would be easier as only this "keyword" would have to be known to the parser
> in a number of languages.)
> > *   Dates would be self-explanatory, to a clever parser.
> > *   Any list of words separated by commas on a single line would be
> treated as tags.
> > *   Any more fanciful meta descriptors might be given explicitly just as
> in MMD before. This could be left to non-standard, personalized variants of
> Markdown.
> >
> > 

Re: Metadata syntax (was Universal syntax for Markdown)

[David Chambers]

On Sep 18, 2011, at 10:47 AM, John MacFarlane wrote:

> * There's no provision for structured data (e.g. key/value
>  tables or lists), or for boolean or numerical fields.

I'm not convinced that Markdown should have any say as to which data structure 
a particular value should be transformed into.

These are the things I believe Markdown certainly should define:
delimiters for metadata blocks (whitespace or otherwise)
syntax for key–value pairs
valid keys
valid values
Perhaps Markdown's responsibilities should be limited to the following:
ensuring that metadata are omitted from the HTML output
storing the key–value pairs (as strings) in a dictionary-like object
The reason I lean towards this approach is that the alternative (defining 
syntax for lists, numbers, etc.) would impose extra syntax in common cases. 
Take the following, for example:

date: Sunday, 22 May 2011
time: 6:30pm
zone: America/Los_Angeles
tags: JavaScript, regex, regular expressions

To a human reader, "tags" is clearly a list. How, though, would a parser know 
that "tags" is a list but "date"—which also contains a comma—is not? Resolving 
this ambiguity would require that the tags be wrapped in square brackets (or 
the addition of some other syntax):

date: Sunday, 22 May 2011
time: 6:30pm
zone: America/Los_Angeles
tags: [JavaScript, regex, regular expressions]

What if list items are allowed to contain commas? Perhaps an item may be quoted 
to resolve this ambiguity. What happens, then, if one wishes to include a 
quoted item:

tags: [foo, bar, "baz!"]

If quotation marks are optional, would this necessitate wrapping "baz!" in an 
extra pair?

These are certainly edge cases, but as we've agreed defining correct behaviour 
in such cases is important. If we want to avoid defining our own serialization 
format, we have two options: we can adopt an existing format (such as JSON or 
YAML), or we can hand off the responsibility to application developers.

I favour the latter, because serialization formats, by necessity, contain quite 
a bit of punctuation. Transforming strings from a metadata dictionary into 
appropriate values is something with which I have first-hand experience. Mango 
provides a META_LISTS setting which determines which keys' (string) values 
should be transformed in lists. Sure, this required a bit of work on my part, 
but the end result is pleasing (no extra punctuation in my Markdown files).

Won't this lead to a situation where one application cannot correctly process 
another application's metadata? Yes. If we're unwilling to accept this I fear 
we'll end up reinventing YAML. ;)

David


On Sep 18, 2011, at 11:07 AM, Fletcher T. Penney wrote:

> 
> On Sep 18, 2011, at 1:47 PM, John MacFarlane wrote:
> 
> 
>> To my mind, multimarkdown comments just aren't flexible enough:
>> 
>> * There's no way to have multiline metadata fields that contain
>> blank lines, e.g. an abstract with two paragraphs.
> 
> True - but in MMD an abstract would be included in the document with a 
> separate header, not as metadata.  But you're correct that blank lines are 
> not allowed.  I've never needed them, but they aren't allowed.
> 
>> * There's no provision for structured data (e.g. key/value
>> tables or lists), or for boolean or numerical fields.
> 
> True.  I've never needed them, and have never had them requested.  But there 
> is no provision for that.
> 
>> * Metadata fields are interpreted as raw strings, not markdown.
>> That's sometimes what you want, but not always.  Titles
>> often contain emphasis and other formatting, for example,
>> and sometimes even footnotes (for acknowledgements).  If
>> these are just going into an html meta field, it doesn't much
>> matter, but if you're using the metadata fields in templates,
>> it does.  (And sure, you could always run a raw string through
>> your markdown processor again, before passing it to the template engine,
>> but that creates problems for things like reference links and
>> footnotes.)
> 
> This is a slight difference in behavior from MMD 2.  I'm considering 
> approaches to allow processing the contents of the metadata, as this can be 
> an issue occasionally.
> 
>> Another major problem, in my view, is that if a document starts
>> with a phrase followed by a colon, it gets swallowed into metadata:
>> 
>>   % multimarkdown
>>   To be or not to be: that is the question.
>>   ^D
>>   
>>   
>>   http://www.w3.org/1999/xhtml";>
>>   
>>   
>>   
>>   
>> 
>>   
>>   
>> 
>> That's not what most authors would expect!
> 
> This is true.  But a blank line at the top of the document solves the 
> problem.  And it doesn't match a URL on the first line as metadata, so I'm 
> not sure how often this really happens in real life.
> 
>> For this reason, I would favor something more like reStructuredText
>> field lists, which marks the fields explicitly as fields:
>> 
>>   :title:Here is the title.
>>   :author:   John
>>   :abstract: The abstract here.
>> It can span mu

Re: Mou - Markdown editor for web developers

[David Chambers]

> the meme of markdown-based editors -- which is already
> in full bloom on i.o.s. machines -- is coming to the mac...


Indeed. It's great to see. :)

David


On Oct 2, 2011, at 1:01 PM, bowerb...@aol.com wrote:

> chen lou said:
> >   I made a new markdown editor for Mac, named Mou 
> 
> congratulations!
> 
> i'm not running lion yet, but your screenshots look great.
> 
> the meme of markdown-based editors -- which is already
> in full bloom on i.o.s. machines -- is coming to the mac...
> 
> fletcher, you better put your machine in gear...
> 
> -bowerbird
> ___
> 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: let's see what the app store says

[David Chambers]

Alan Hogan  wrote:

I bet if we all got together and had a couple drinks, there'd be none of
> this silly name-calling.


Great point. At the end of the day we're all intelligent people with common
interests who enjoy discussing ideas. Exactly the sort of people I like to
drink with.

David


On 21 November 2011 12:00, Christian Sciberras  wrote:

> Yay! Never mind trolls, let's all burn Apple haters!
>
> Oh I know, while at it, let's all start posting at disjointed threads too.
>
> Who cares about flooding mailboxes, just ignore an email or two, no?
>
>
>
>
>
>
>
> On Mon, Nov 21, 2011 at 5:58 PM, Thomas Humiston wrote:
>
>> Never mind, I found the link.
>>
>>
>>
>> On Nov 21, 2011, at 11:56 AM, Thomas Humiston wrote:
>>
>> > Does this list have a moderator?
>> >
>> >
>> >
>> > On Nov 21, 2011, at 11:38 AM, Chad Nelson wrote:
>> >
>> >> On Mon, 21 Nov 2011 17:22:25 +0100
>> >> Christian Sciberras  wrote:
>> >>
>> >>> He's been called a troll several times before, what make his Apple
>> >>> propagandist remarks any better now?
>> >>>
>> >>> Or is it that there's too much Apple fanboys to let it pass through,
>> >>> hmm?
>> >>
>> >> Apple may be a religion to some, but it's also the manufacturer of one
>> >> of the arguably most popular platforms in existence today. For a
>> mailing
>> >> list devoted to Markdown, talking about its adoption on that platform
>> >> seems pretty on-topic.
>> >> --
>> >> Chad Nelson
>> >> Oak Circle Software, Inc.
>> >> *
>> >> *
>> >> *
>> >>> On Mon, Nov 21, 2011 at 5:07 PM, Alan Hogan 
>> >>> wrote:
>> >>>
>>  I also find it quite a stretch to call Bowerbird a troll! Usually the
>>  worst you could call him is "opinionated" and "too frequent a poster
>>  for some tastes."
>> 
>>  I found his App Store updates interesting.
>> 
>>  Your vitriol adds nothing.
>> 
>>  I bet if we all got together and had a couple drinks, there'd be
>>  none of this silly name-calling.
>> 
>>  On Nov 21, 2011, at 7:39 AM, Christian Sciberras 
>>  wrote:
>> 
>>  Yeah, it would be ironic of trolls to call each other "troll".
>> 
>> 
>> 
>> 
>> 
>> 
>>  On Mon, Nov 21, 2011 at 1:20 PM, Sherwood Botsford
>>  wrote:
>> 
>> > Someone pee  in your cornflakes this morning?
>> >
>> > I don't see the Bowerbird's post as a troll.  I found it
>> > informative. Until I read that I didn't realize that there were
>> > *ANY* other markdown like front ends other than the one that
>> > Fletcher was working on.
>> >
>> > Mind you it's not a discussion I've followed with care.  My text
>> > editor of choice is vim.
>> >
>> > 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 Mon, Nov 21, 2011 at 4:00 AM, Christian Sciberras
>> > wrote:
>> >
>> >> I'm sure the world will dearly mourn the failures of markdown-based
>> >> crAppStore apps.
>> >>
>> >>
>> >> Now go troll somewhere else, kid.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Nov 19, 2011 at 11:36 PM,  wrote:
>> >>
>> >>> "multimarkdown composer" has been out for 4 weeks now,
>> >>> so let's mosey on over to the app store to see what it says...
>> >>>
>> >>> "composer" is #184 in productivity apps, a bit disappointing,
>> >>> considering that it was in the top-20 when it first came out...
>> >>> it's gained only 5 reviews over the 18 it had right off the bat.
>> >>>
>> >>> perhaps even more surprising, to some, is that "marked" is
>> >>> at #356 in productivity apps, which is a solid indication that
>> >>> the editing+display coupling produced by "composer" trumps
>> >>> the use-any-text-editor-you-like generality "marked" offers.
>> >>> (note also that "marked" is even at a much lower price-point.)
>> >>>
>> >>> and maybe the biggest surprise of all, to some, is the newish
>> >>> "markdownnote", which appears at #115 in productivity apps.
>> >>> "markdownnote" has been available on ipad for a while, and
>> >>> is something of an enigma.  its big liability is that it supports
>> >>> nothing more than gruber's flawed formulation, but its asset
>> >>> is that it has the edit-on-one-side-with-display-on-the-other
>> >>> basic interface which i consider to be vital for this type of app.
>> >>> (you might recall that fletcher disagrees with me on this point.)
>> >>>
>> >>> "markdownnote" pulls off this _simple_interface_ better than
>> >>> any other app i've found so far, which might well help explain
>> >>> its good ranking, as there's little else of note in its
>> >>> feature-set.
>> >>>
>> >>

Re: Python-Markdown 2.1.0 released.

[David Chambers]

Congratulations, Waylan. The Python community is lucky to have you.

David


On 24 November 2011 12:43, Waylan Limberg  wrote:

> Just letting everyone know that I just released Python-Markdown
> 2.1.0.final.
>
> Get from PyPi: http://pypi.python.org/pypi/Markdown/2.1.0
>
> Read the release notes on github:
> https://github.com/waylan/Python-Markdown/blob/master/docs/release-2.1.0.md
>
> --
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> 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: there's no payoff in confusing the users

[David Chambers]

I find discussion of techniques for building Markdown parsers very
interesting. It's slightly off topic, perhaps, but I don't think this list
is large enough to spawn a separate "Markdown implementers" list.

David


On 1 December 2011 16:53, Seumas Mac Uilleachan  wrote:

>  On 12/01/2011 11:37 AM, bowerb...@aol.com wrote:
>
> john said:
> >   Have you considered using a PEG instead of regexes?
>
> for all you home-schooled and self-taught programmers
> for whom "peg" is far too computer-sciencey for comfort,
> consider as an alternative the simple methodology i use...
>
> i split the text-file on blank lines and place it in an array.
>
> that is first-cut for my light-markup format, a.k.a., "zml"
> -- zen markup language -- but it's alright with me if you
> markdown people want to borrow it for your own purpose.
>
> i mean, seriously, it's not like i could patent it, or anything.
> (but, on second thought, perhaps i _should_ at least apply.)
>
> then i walk the array, analyzing each item to see what it is;
> the chunk might get tagged as a blockquote, or a heading,
> or a list item, or a plain old paragraph, or _whatever_ it is.
>
> then i walk the array again, using the tag for each chunk to
> generate the appropriate output for the desired format(s)...
>
> (sometimes the tag, or the output, is dependent upon the
> surrounding chunks, and that's the reason i walk it twice.)
>
> it's the methodology of a simpleton, i am the first to admit,
> but it works, and it works well, and it works sufficiently fast.
>
> best of all, for me, is that it's extremely easy to understand.
>
> even better, for everyone:  it's easy for users to understand.
>
> after all, there's no payoff in confusing the users.  is there?
>
> -bowerbird
>
> p.s.  "alright" is a word i like to use...  it's akin to "already"...
>
>
> ___
> Markdown-Discuss mailing 
> listMarkdown-Discuss@six.pairlist.nethttp://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>  What confuses me is what this all has to do with markdown.
>
> ___
> 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: Disappointed

[David Chambers]

Hi John,

I don't think you'll find usage tips discussed here very often, aside from
recurring questions such as “How does one include consecutive code blocks
or consecutive unordered lists?” As with most mailing lists, you're likely
to find only a portion of the posts interesting. From time to time, though,
there is interesting and constructive discussion. It tends to focus on ways
in which Markdown is being incorporated into software and ways in which the
language itself is being extended.

David


On 16 December 2011 09:57, John R. Rambo  wrote:

> I have subscribed to this list for about a month now.
>
> I am just a MarkDown user; new to it. Using it within *Ema Personal Wiki
> & Epistle* for Android.
>
> I am not trying to implement this cool little light language into an app I
> am developing; maybe someday.
>
> I signed up because I thought I might get some MarkDown use tips.
>
> *I have learned nothing from this list.*
>
> I have witnessed a lot of bitching (which I guess you could accuse me of
> now) and in-fighting. Adults acting like children.
>
> I just read a long post about how "no one is listening to me"
>
> Waah. Waah.
>
> Probably going to unsubscribe; so far all of these emails have just been
> DELETE, DELETE, DELETE.
>
> I hope to gather some useful knowledge on this little light markup
> language. I suspect I'll not find it here. Sad.
>
> Save your flames, I'll not engage, I'll just unsubscribe & go sit at the
> big-people's table.
>
> John
>
> --
> -- John R. Rambo
>
> ___
> 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: here's the thing that tips the scale

[David Chambers]

Sherwood Botsford  wrote:

2.  Build a web page.  On that web page:
> a.  There is a page with the full syntax of BMD done in the tutorial style
> of  John Gruber's page. Syntax differences from MMD are highlighted in
> skyblue pink.
> b.  There is a page showing the desired output coded as standard MMD and
> as BMD so that people have a large size sample to work with and look at.


Excellent suggestions, Sherwood, particularly the points above.

bowerbird, you should make this happen. It'd be great to see a comparison
of Markdown and zml; I'd also like to read the source code for your
converter. I find the notion you espouse — that simple grammar rules make a
language easier for users to understand and also easier to implement — very
appealing.

David


On 16 December 2011 09:22, Chris Lott  wrote:

> On Thu, Dec 15, 2011 at 5:00 PM,   wrote:
> > ok, i waited for 2 weeks, and still no votes -- none! --
> > on whether my posts are sufficiently on-topic, or not...
>
> I'm interested, consider your posts generally on-topic, and would
> rather you stuck around. After all, there is no fun in an
> echo-chamber.
>
> c
> --
> Chris Lott 
> ___
> 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: Inline HTML link and mailto: link

[David Chambers]

>
> How are em-dashes and en-dashes handled in Markdown?


You can include Unicode characters in Markdown documents, so go ahead and
use the actual characters if you want to. On OS X, ⌥- produces an en dash
and ⇧⌥- an em dash.

Many Markdown implementations offer extensions which allow "--" to be used
to represent an en dash and "---" to represent an em dash.

David


On 13 January 2012 10:15, R (Chandra) Chandrasekhar wrote:

> Wow, that was a quick reply!
>
> Yes, indeed, I was putting a space between ] and (. I have corrected that
> and now both the links work as they should :-).
>
> May I ask a supplementary question please: How are em-dashes and en-dashes
> handled in Markdown?
>
> Thank you.
>
> Chandra
>
>
> On Friday 13 January 2012 11:30 PM, Alan Hogan wrote:
>
>> Are you putting spaces between ] and ( ? You shouldn't.
>>
>> ajh
>>
>> On Jan 13, 2012, at 9:52 AM, "R (Chandra)
>> Chandrasekhar">  wrote:
>>
>>  Dear Folks,
>>>
>>> I am just starting out with Markdown and am trying to get two
>>> elements working:
>>>
>>> (1) An inline HTML link; and
>>>
>>> (2) An inline mailto: link
>>>
>>> as shown in the text below:
>>>
>>> We invite you to [browse] 
>>> (http://academy.swanlotus.com/**index.html
>>> )
>>> this website. Take a look and see if you find anything useful. And
>>> do [drop us a line] (mailto:feedb...@swanlotus.com**) with your
>>> comments for improvement.
>>>
>>> I tried it out on Dingus and failed to get the expected HTML
>>> version like:
>>>
>>> We invite you to>> href="http://academy.**swanlotus.com/index.html
>>> ">**browse  this
>>> website. Take a look and see if you find anything useful. And do>> href="mailto:feedback@**swanlotus.com ">drop us
>>> a line  with your
>>> comments for improvement.
>>>
>>> Instead, Dingus gave me:
>>>
>>> We invite you to [browse] 
>>> (http://academy.swanlotus.com/**index.html
>>> )
>>> this website. Take a look and see if you find anything useful. And
>>> do [drop us a line] (mailto:feedb...@swanlotus.com**) with your
>>> comments for improvement.
>>>
>>> This is my first experience with Markdown, although I am conversant
>>> with HTML and very conversant with LaTeX.
>>>
>>> What am I doing wrong and why am I not getting the expected HTML
>>> markup?
>>>
>>> FYI, I am on Kubuntu 11.10 using Markdown, version 1.0.1 from the
>>> standard .deb package.
>>>
>>> Thanks in advance.
>>>
>>> Chandra __**_
>>> 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
>>
>
>
> --
> --
> R (Chandra) Chandrasekhar
> Web: http://swanlotus.com
> email: chyav...@gmail.com
> --
>
> __**_
> 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: a blade of grass cracks the sidewalk

[David Chambers]

Nice one, bowerbird.

I have one suggestion, which is that the textarea should use a monospace
font so that, for example, table columns are aligned.

David


On 20 April 2012 17:44,  wrote:

> alan said:
> >   Congrats on shipping a nice dingus, Bowerbird.
>
> i'm hoping someone with design chops takes pity on me,
> and contributes something that looks significantly better.
> but at base, it's just a 2-pane tool, so that's what matters.
>
>
>
> >   It does indeed look like
> >   an extremely clean and powerful syntax.
>
> that's what i was aiming at, yes.  easy to understand,
> as a naive user, and easy to handle, as a programmer.
> delivering great functionality while remaining simple.
>
>
>
> >   What causes the entire first page to be in bold?
> >   Convention?
>
> mostly convention, yes.
>
> the target is books, so the first section/page is defined as
> the cover/title-page, which is traditionally centered bold.
>
> but where there is a lot of text, such as on the example,
> bold may be overkill, so that's something i might change.
>
> i've been closely examining books for several decades now,
> so i have a very firm idea about what my starting place is...
> but i'm also quite flexible to the ways authors and readers
> want to shape e-books to fulfill their destiny, which means
> i am going to be quite attentive to the feedback they give...
>
> i don't anticipate that _a_lot_ will change, but _everything_
> is up for questioning; nothing is too sacred to be touched.
>
>
>
> >   Styles applied after your transformation to HTML?
>
> i'm not quite sure what you're asking.
>
> there isn't a whole lot of styling going on, as you'll see
> if you view source.  it's intentionally quite barren, since
> the e-book viewer-programs today ignore most styling,
> and substitute in their own, so it's best to just surrender.
>
> another consideration is that my philosophical bent is that
> it's the reader who should set many of the styling options.
> so my viewer-program will allow the reader to customize.
> part of the preparation for that is to get authors used to
> the notion that they no longer control the look-and-feel.
> (especially not with a tool that does the grunge for them.)
>
> so it's a combination of both practical and philosophical.
>
> having said all of that, the styling process is one of those
> things on which i'll be actively soliciting input from users.
>
> also, for instance, it would certainly be possible to offer
> authors the option of using their own c.s.s. stylesheet...
>
> and even if i didn't offer them that, it's not like they can't
> simply edit the .html output before they go public with it.
>
> what i haven't shown yet is that the .html gets wrapped up
> into an .epub, and a .mobi, and a .pdf is created as well...
> but you also get the .html files that build the .epub/.mobi.
> (the 4, x, and 5 buttons display the various .html outputs.
> right now, they're virtually identical; but they could fork.)
>
> -bowerbird
>
> p.s.  and yes, to all you haters whose mouths are frothing...
> if this conversation persists for long, we'll take it elsewhere.
> but if it makes you feel better, please post your rant anyway.
>
> ___
> 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: [text][index](url) syntax

[David Chambers]

>
> What do you think about that? Godd idea? Crap?


Not a good idea, in my opinion. Markdown provides two ways to define links,
which are sufficient given that one provides the reusability you desire. As
a reader of a Markdown document, I prefer the links to be in one place
(generally at the bottom of the document). Inline links are fine, too. The
option you present would make it difficult to find the URL for a link via a
quick scan of a document.

David


On 30 May 2012 14:14, Alan Hogan  wrote:

> I haven’t ever seen that used in plaintext writing before, which would
> make the syntax probably violate the principle of being derived from email
> list / plain text patterns.
>
> More concerning is that now potentially literal brackets that were
> adjacent to a link, if anyone had that, would now be linked and more
> importantly the link text would be hidden. But maybe that’s not so common.
>
> Personally, I don’t see why it’s a big problem to just define the link at
> the bottom if you want to use it in several places.
>
> But, you did get me thinking. It would be interesting if there was a magic
> named link, "ibid.", which always refer to the preceding link, in context.
> So:
>
>[One](http://one.example.com), [two][ibid.], [three][ibid.], [four][],
> [five][ibid.]
>
>[four]: http://four.example.com
>
> Would generate three links to one.example.com and two to four.example.com.
>
> (If the user had manually defined a link named "ibid." then that would
> take precedence over the magic implementation. And of course, the first
> link in the document cannot be an 'ibid.' link; I suppose the behavior
> should be to either output a link with no href value or just emit the plain
> text.)
>
> On May 30, 2012, at 1:59 PM, Jakob wrote:
>
> > Hi there! I wanted to drop a line on the markdown syntax used for links:
> >
> > When i reference to [some website][1] and want to do [the same
> reference][1] later ai can only do this in endnote style (or howeer it's
> called). What i would want to be able to do is to make [an inline reference
> to a website][2](http://anotherexample.com) and be able to reuse [that
> reference][2] just the same.
> >
> > What do you think about that? Godd idea? Crap?
> >
> > Regards,
> >
> > Jakov
> >
> > [1]: http://example.com
> >
> > ___
> > 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: Multidingus

[David Chambers]

This is a terrific tool, John. I now realize how much disagreement there is 
between the different Markdown libs on certain topics (such as consecutive 
lists).  

David  


On Friday, 19 October 2012 at 2:51 PM, John MacFarlane wrote:

> +++ Alan Hogan [Oct 19 12 14:07 ]:
> > Here’s a tiny bookmarklet that can be run on Babelmark 2 as it stands
> > today, that replaces all the  elements on the page with an HTML
> > preview:
> >  
> > javascript:$('pre').each(function(i, el){ var html = $(el).text();
> > $(el).replaceWith($('').html(html)); });
> >  
> > Or, you may drag it into your bookmarks page from here:
> >  
> > <[1]http://peg.gd/2IU>
> >  
> > It’s not Good Code and doesn’t do anything useful like add tabs to
> > switch between representations, but hey, I spent five minutes on this
> > and it’s kind of useful, so I’m sharing it.
> >  
>  
>  
> Alan,
>  
> This is useful. I've incorporated it into the site itself, so you
> can now toggle between "Preview" and "Code" modes. When I have a bit
> of time I'll make it use tabs for this instead -- that would be nicer.
>  
> John
>  
>  
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: Trouble with parentheses in Markdown hyperlinks

[David Chambers]

I registered markdown.io for a year but did nothing with it during that time, 
so let the registration lapse. I'm happy to reregister this domain name (or to 
register a different one) and to point it at the appropriate nameservers.

David 


On Monday, 22 October 2012 at 8:24 PM, Boris Le Ninivin wrote:

> On 10/23/2012 02:37 AM, David J. Weller-Fahy wrote:
> > Ah-hah! I knew I was too tired when I responded - let me clarify.
> > 
> > I don't believe we'll need fcgiwrap or Nginx, as I already have a
> > functional setup of ikiwiki running under mathopd, and can duplicate
> > that for another user easily enough.
> > 
> 
> Your VPS, your call. :)
> > I can do the initial setup of the wiki and gitolite, assuming the
> > gitolite configuration is not rocket science (TM). I'll run the wiki
> > under an isolated user, set some reasonable defaults, and then get you
> > setup as the administrator. Note, I'm committing to donating VPS
> > hosting, but not to being the active maintainer of the wiki. I would
> > hand that over to you, and would be a sometime helper, but RL does not
> > allow for much free time.
> > 
> 
> Same here, so it might be great if a couple of other people would ask 
> for an access (id_rsa.pub) via git too; so they can put things we forget 
> (or don't have the time to add) in the wiki.
> > I can get those items done within the next few days (before Friday,
> > certainly), and then we can test connectivity and make sure you have
> > full access to the wiki's repository.
> > 
> 
> Depending on the availability of the virtual-server manager of the 
> French association I mentionned before, I might already have (I've asked 
> a few days ago, but they have much to do apparently) a working VPS at 
> this point... So... Wait and see...
> > To make sure I fully understand: The intent of this Wiki would be to
> > provide a central repository for documentation about Markdown, the
> > variants available (including the 1.2b8 and other semi-official
> > variants), the quirks and bugs of each, and start working toward
> > community convergence w.r.t. a future "Markdown2," or whatever it will
> > be called. Did I capture that correctly?
> > 
> 
> Same idea here yes. Plus a link to a (list of the?) multi-dingus, if 
> available.
> > Final item: What temporary* subdomain does the community want? I can
> > put anything on the front of my "caterva.org (http://caterva.org)," and was 
> > tempted to just
> > create "md.caterva.org (http://md.caterva.org)," but realized others may 
> > have a preference. So:
> > What say y'all?
> > 
> 
> I was thinking about using a domain under a "first level TLD" such as 
> mdwn.tk (http://mdwn.tk). The thing being : We (or you) HAVE to set up a 
> working wiki 
> with some (even minimal) content before we ask for the domain, or it 
> will be taken down in minutes (their policy is quite restrictive about 
> non-resolving websites and inactivity). What do the others on the list 
> think?
> > *: There is nothing more permanent that a temporary measure, so I tend
> > to assume temporary names are going to be permanent now. ;)
> > 
> > Anyway, that's my brain-bytes for now. If I missed anything or there
> > are questions throw them out there.
> > 
> > Regards,
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: How to insert a blank line between blockquote paragraphs?

[David Chambers]

Another (ugly) option: 


quote 1



quote 2




quote 3



This is no good, though, if the quotes contain markup of their own, as you'll 
be forced to write that in HTML too.

David 


On Wednesday, 24 October 2012 at 1:27 PM, Waylan Limberg wrote:

> On Wed, Oct 24, 2012 at 4:18 PM, Waylan Limberg  (mailto:way...@gmail.com)> wrote:
> > On Wed, Oct 24, 2012 at 4:09 PM, Thomas Maibaum  > (mailto:thomasmaib...@gmail.com)> wrote:
> > > Hello everyone,
> > > 
> > > First off, I'm new to this list, so if this has been dealt with before, I
> > > apologize. I was unable to find a solution in Google.
> > > 
> > > My question is, how do I insert a blank line between blockquote paragraphs
> > > so that they are visually separate? I often need to put two or three
> > > separate blockquotes in a row, without any regular text between them, but
> > > Markdown always renders the HTML output like one long quote. Like this:
> > > 
> > 
> > 
> > Well, if you don't want the output to be visible, and as Markdown
> > accepts raw html, why not an html comment. Like this:
> > 
> > http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%0A%3C!--+blank+line+--%3E%0A%0A%3E+bar%0A%0A%3C!--+blank+line+--%3E%0A%0A%3E+baz
> 
> You can even eliminate some of the blank lines like this:
> 
> http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%0A%3C!--+blank+line+--%3E%0A%3E+bar%0A%0A%3C!--+blank+line+--%3E%0A%3E+baz
> 
> Although that breaks pandoc in strange ways. However, all other
> implementations handle that fine and you save a few blank lines in
> your document. The rest are necessary though.
> 
> -- 
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: Trouble with parentheses in Markdown hyperlinks

[David Chambers]

On Wednesday, October 24, 2012 at 7:25 PM, John MacFarlane wrote:

> Github has wikis for each project.
> Example: https://github.com/jgm/pandoc/wiki
> 
> You'd only have to create a 'markdown' project, which needn't have
> anything in it but a README.markdown file with a link to the wiki.
> Anyone with a github account could edit the wiki.
> This seems far easier than any of the other proposals.



I created the markdown (https://github.com/markdown) account on GitHub some 
time ago. If there's support for John's suggestion, we could create a public 
repository in that account and use its wiki.

David 


On Wednesday, October 24, 2012 at 7:25 PM, John MacFarlane wrote:

> +++ Andrew Pennebaker [Oct 18 12 09:52 ]:
> > What I'm saying here is that relying on 3rd parties solutions while a
> > very cheap (or even free) VPS would be sufficient is asking for
> > unnecessary trouble.
> > 
> > I agree that we should opt for convenient, preferably free hosting.
> > I don't mean to start a technical argument about "static" vs "dynamic"
> > web pages. What I'm trying to convey is that GitHub, while an
> > incredibly easy CMS, only supports static web pages, not wikis, which
> > require a running system that can modify a database for wiki edits.
> > 
> 
> 
> Github has wikis for each project.
> Example: https://github.com/jgm/pandoc/wiki
> 
> You'd only have to create a 'markdown' project, which needn't have
> anything in it but a README.markdown file with a link to the wiki.
> Anyone with a github account could edit the wiki.
> This seems far easier than any of the other proposals.
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: How to insert a blank line between blockquote paragraphs?

[David Chambers]

> http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%0A%3E+bar%0A%0A
 
(http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%0A%3E+bar%0A%0A)
I love pandoc's approach here. It's logical, and makes it just as trivial to 
mark up consecutive single-paragraph quotes as it is to mark up a two-paragraph 
quote.

This is exactly the sort of thing that could be profitably discussed were we 
not bound by the somewhat inconsistent behaviour of the original Perl script. 
Do others agree that pandoc's treatment of such cases is preferable to the 
“specified” behaviour? What I'm asking is what others would advocate if we were 
discussing a hypothetical format with no backwards-compatibility concerns. 
(Let's not have every discussion derailed by the backwards-compatibility 
discussion.) :)

David  


On Wednesday, October 24, 2012 at 6:22 PM, John MacFarlane wrote:

> See question 6 here:
> http://johnmacfarlane.net/babelmark2/faq.html#what-are-some-big-questions-that-the-markdown-spec-does-not-answer
>  
> And note that pandoc allows you to create two blockquotes if
> you leave blank space between,
>  
> http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%0A%3E+bar%0A%0A
>  
> If you want one blockquote with two paragraphs, do it like this:
>  
> http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+foo%0A%3E%0A%3E+bar%0A%0A
>  
> Unfortunately the other implementations don't make this distinction.
>  
> +++ Thomas Maibaum [Oct 24 12 22:09 ]:
> > Hello everyone,
> >  
> > First off, I'm new to this list, so if this has been dealt with before,
> > I apologize. I was unable to find a solution in Google.
> >  
> > My question is, how do I insert a blank line between blockquote
> > paragraphs so that they are visually separate? I often need to put two
> > or three separate blockquotes in a row, without any regular text
> > between them, but Markdown always renders the HTML output like one long
> > quote. Like this:
> > > Quote #1
> >  
> > [line break followed by empty line or spaces]
> > > Quote #2
> >  
> > [line break followed by empty line or spaces]
> > > Quote #3
> >  
> >  
> > It always ends up looking the same as this:
> > > Quote #1 [regular linebreak]
> > > Quote #2 [regular linebreak]
> > > Quote #3 [regular linebreak]
> > >  
> >  
> >  
> > So far, I've always put an acute accent ( ´ ) between the quotes,
> > because it was the least obtrusive character I could think of:
> > > Quote #1 [regular linebreak]
> >  
> > ´
> > > Quote #2 [regular linebreak]
> >  
> > ´
> > > Quote #3 [regular linebreak]
> >  
> >  
> > But of course this is still an ugly workaraound. Is there another way
> > to go about this?
> >  
> > Looking forward to any hints,
> >  
> > Thomas
>  
> > ___
> > Markdown-Discuss mailing list
> > Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> > http://six.pairlist.net/mailman/listinfo/markdown-discuss
> >  
>  
>  
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: Trouble with parentheses in Markdown hyperlinks

[David Chambers]

> David if you make that user account an "organization" then if/when you ever 
> lose interest in or run out of time to maintain it, you can share with or 
> pass ownership off to any other github user - with no need to pass off 
> control of a hosting account or move it to a new hosting account or transfer 
> control of a domain ... and all the other relevant headaches with that sort 
> of thing.

Terrific idea. github.com/markdown (https://github.com/markdown) is now an 
organization. Anyone interested in being added as a member can send me a 
message with their GitHub username.

David 


On Wednesday, 24 October 2012 at 9:03 PM, Waylan Limberg wrote:

> On Wed, Oct 24, 2012 at 11:18 PM, David Chambers
> mailto:david.chambers...@gmail.com)> wrote:
> > On Wednesday, October 24, 2012 at 7:25 PM, John MacFarlane wrote:
> > 
> > Github has wikis for each project.
> > Example: https://github.com/jgm/pandoc/wiki
> > 
> > You'd only have to create a 'markdown' project, which needn't have
> > anything in it but a README.markdown file with a link to the wiki.
> > Anyone with a github account could edit the wiki.
> > This seems far easier than any of the other proposals.
> > 
> > I created the markdown account on GitHub some time ago. If there's support
> > for John's suggestion, we could create a public repository in that account
> > and use its wiki.
> > 
> 
> 
> +1 from me.
> 
> There used to be an old wiki (I forget where) which lasted for some
> years. But it died a slow death. First from lack of maintenance, then
> from spam, then from being locked down to avoid the spam. No longer
> being publicly editable was the last nail in its coffin. At least
> that's the way I remember it.
> 
> The thing about github it that is has user management features to help
> with spam, etc. (not that other wiki systems don't but...) David if
> you make that user account an "organization" then if/when you ever
> lose interest in or run out of time to maintain it, you can share with
> or pass ownership off to any other github user - with no need to pass
> off control of a hosting account or move it to a new hosting account
> or transfer control of a domain ... and all the other relevant
> headaches with that sort of thing.
> 
> Also, as a bonus, the default page url (using github pages) would be
> markdown.github.com (http://markdown.github.com) - which is even better that
> github-flavored-markdown gets. Sure, that page wouldn't be as easily
> editable as a wiki, but just make it static with general info and a
> link to the wiki - or don't - use pull requests as moderated editing
> of the github page. Trusted and frequent editors of the doc (and/or
> implementation authors) could be given full editing privileges of the
> underlying repo using there respective user accounts (which privileges
> could still be revoked upon abuse).
> 
> For that matter, as an "organization", each implementation author
> could host their implementation under markdown/[implementation_name].
> Or if they don't want to, auto-updating mirrors could be added
> (although, unfortunately, the auto-updating script would need to be
> maintained externally). Great for one-stop shopping for all
> implementations. I know I'd use it to browse markdown.pl 
> (http://markdown.pl)'s source -
> rather than downloading the zip file.
> 
> -- 
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto: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: Another Markdown-like markup language

[David Chambers]

> The comments do not appear in the rendered HTML.

It looks as though the comments *do* appear in the output. Is this just the
case in the "playground"?

David


On 17 December 2012 15:51, Stuart Rackham  wrote:

> I released Rimu Markup (http://rimumarkup.org/) a week ago, it may
> be of interest to Markdowners.
>
>
> Cheers, Stuart
> ___
> 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: footnote:id, colons and jquery

[David Chambers]

I sometimes find colons useful. Here's an example:

resume.pdf

Using "ext:pdf" rather than "ext-pdf" makes it clearer that this class name
acts as a key–value pair. Sure, I could use `data-extension="pdf"` here
instead, but selector engines are optimized for finding elements by class
name.

In the case of CSS, all that's required is a backslash to escape the colon:

.c10n .c10n-file.document.ext\:pdf {
  background-image: url(assets/fugue/document-pdf-text.png);
}

In my view it's fine to include colons in ids, but I'm not strongly opposed
to the *pragmatism not idealism* stance.

David


On 23 January 2013 17:12, Michel Fortin  wrote:

> Le 23-janv.-2013 à 14:29, Waylan Limberg  a écrit :
>
> > I just received a [bug report] for Python-Markdown complaining that
> > colons are used in the ids of footnotes. For reference, we [output]
> > the same format at PHP Markdown Extra. The general complaint is that
> > the colon in the id attribute (`id="fnref:1"`) causes jquery to choke
> > when referencing that id from javascript because jquery uses colons to
> > indicate pseudo elements (as does CSS). As expected, jquery supports
> > escaping the colon - which eliminates the problem - except that
> > apparently the escaping causes a performance hit.
> >
> > My initial reaction is to say that this is jquery's problem, but what
> > do you think? Should the various implementations that support
> > footnotes all change to not use colons? I couldn't help but note that
> > Gruber's unreleased implementation (what he uses on
> > daringfireball.com) appears to use dashes instead.
> >
> > Any thoughts?
>
> Interestingly, I've been looking at updating the output for footnotes in
> PHP Markdown, although not the id attribute.
> 
>
> My guess is that Jquery has an optimization for the common pattern
> "#nocolon" and that putting an escape forces it to take the slow path. Take
> his example and add a class name (making the selector "#nocolon.anyclass"),
> or put an ancestor (as in "body #nocolon") and you'll get equal speed
> everywhere.
>
> --
> Michel Fortin
> michel.for...@michelf.ca
> http://michelf.ca/
>
> ___
> 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: attribute blocks for definition lists

[David Chambers]

This strikes me as a sound suggestion. It would allow us to use a
definition list where currently we'd be forced to use headings and
paragraphs.


On 1 July 2013 08:33, Matthieu Codron  wrote:

> Hello,
>
> As I am using markdown to write documentation, I am often tempted to make
> links to terms in definition lists.
>
> Since this is not possible for now (at least in php markdown extra), I was
> wondering if this could be a common addition in major implementation
> supporting definition lists.
>
> the syntax would be
>
> term {#id}
> :   definition
>
> This syntax tries to follows current convention and use the similarity
> between titles and terms.
>
> Matthieu
>
> ___
> 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: fan_fucking_tastic

[David Chambers]

… or possibly intraword italics, which I seem to recall someone being
surprised by recently.


On 5 July 2013 16:38, Alan Hogan  wrote:

> On Jul 5, 2013, at 4:24 PM, Wolfgang Faust  wrote:
>
> While I empathize with your predicament, I generally prefer not to have
> expletives in my inbox. Also, what has this to do with markdown?
>
> bowerbird is referencing his observation-as-parable from [two weeks ago]
> that many problems with Markdown repeatedly come up here (and elsewhere),
> to be acknowledged but satisfactorily resolved. It was prompted by [another
> person struggling with parentheses in URLs].
>
> [two weeks ago]:
> http://six.pairlist.net/pipermail/markdown-discuss/2013-June/002850.html
> [another person struggling with parentheses in URLs]:
> http://six.pairlist.net/pipermail/markdown-discuss/2013-June/002845.html
>
> Alan Hogan
>
>
> ___
> 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: what this has to do with markdown

[David Chambers]

thank you for taking the time to share these thoughts, bowerbird. much
food for thought.


On 7 July 2013 20:00, Sherwood Botsford  wrote:

> Bowerbird, after this epistle, I promise to read you more thoroughly.
>  Nicely put.
>
>
>
> 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 7 July 2013 20:21, bowerbird  wrote:
>
>> first, i'm sorry for the expletive in your in-box.  really.
>>
>> i also apologize for the smell from those dead skunks.
>>
>> ***
>>
>> as to "what this has to do with markdown", it's simple.
>>
>> if i remember correctly -- i might not, but who cares? --
>> "fan_f*ck*ng_tastic" was the word gruber used to justify
>> his choice that his version of markdown would recognize
>> intraword italics.  so that's why _i_ used that one as well.
>>
>> now, the reason i followed it up with my reference to the
>> dead-skunk problem is because it's almost perfect as a
>> demonstration of the full range of problems these days...
>>
>> a person comes in and says, "hey, i noticed this glitch".
>>
>> somebody else says "here's a workaround you can use."
>>
>> which -- first -- ignores the fact that it's after-the-fact.
>>
>> but, in this particular case, the suggestion was actually
>> better than most.  to remind you, the workaround was to
>> surround filename_withanunderbar.txt with `backticks`,
>> which marks it as `code`, and thus short-circuits italics.
>>
>> because, as the suggester pointed out, it is the case that
>> you probably _want_ filenames to be marked as `code`,
>> so they will display in a different typeface, and stand out.
>>
>> the problem with that tactic, however, is that it does not
>> address the situation where you would want the word to
>> be rendered with the same typeface as surrounding text.
>> you wouldn't want "fan_f*ck*ng_tastic" marked as code.
>>
>> so...  sticking with the problem in regard to filenames...
>>
>> another workaround would be to backslash/escape the
>> underbar in the filename, which will also nix the italics,
>> but that presents a different problem, which is that now
>> we've gummed up the plain-text version of the filename
>> with an unwanted backslash, with unknown side-effects.
>> (since you just know somebody is going to end up using
>> that now-improper filename, and they will suffer for it.)
>>
>> that same type of problem would likely manifest with the
>> "just use raw .html" workaround, even if you can find the
>> way to concoct that.  (it hurts my brain to think about it;
>> i'm using light-markup so i'm not forced to do raw html.)
>>
>> the fact is, we really want to leave a filename untouched.
>> but we also don't want its underbars to be italic triggers.
>>
>> and remember that when an underbar is misrecognized
>> as an italic-trigger, it's dropped from .html output, so
>> we now have _another_ wrong version of that filename,
>> in addition to the difficult problem of the runaway italics.
>>
>> and, just to remind y'all that this is even _more_ thorny,
>> this underbar problem also happens regularly with urls.
>>
>> (there are other instances too, but i do not intend to
>> share all of the results from my hard-fought research;
>> since url's have the problem, it is significant enough.)
>>
>> this is not a thing we can casually sweep under the rug.
>>
>> which is why some markdown script-writers have just
>> decided that they will _disallow_ intraword underbars.
>>
>> and, in defense of that decision, it is the absolute truth
>> that browsers make a sad tragedy with intraword italics.
>> go look at some, take a hard look, and you _will_ see it:
>> the italic characters either slant into the upright ones, or
>> lean far too far away from them. either side, it's _awful_.
>>
>> so yes, many markdown scripters do an outright ban...
>>
>> which is fine if you are god, and you make the decisions.
>>
>> but if you are beholden to users, it might not be so good.
>>
>> and if you consider yourself to be a _servant_of_writers_,
>> then you really need to do a bit of research (or lots of it)
>> to discern if writers actually do ever use intraword italics.
>>
>> that was what i did, as i was developing my light-markup.
>>
>> so i can tell you that, yes, indeed, writers _do_ use them.
>>
>> not a lot, of course, but they're not that infrequent either,
>> and it is a sizable percentage of writers that do use them.
>>
>> so that's probably why about _half_ of the implementations
>> ban 'em, and half _allow_ them.  it's split down the middle.
>>
>> so if you really want to know if it's acceptable to ban them,
>> my advice would be "no".
>>
>> ***
>>
>> now, let's go back and look what the original poster said.
>>
>> >   Why not to ignore all "_"
>> >   which are not followed or preceded
>> >   either by a whitespace or by a newline?
>>
>> just for the record, a newline _is_ whitespace, so we can
>> strike the "or 

Re: Media block

[David Chambers]

Are you suggesting that a paragraph consisting solely of text that looks like a 
URL should be treated specially based on its file extension? Something along 
these lines could work, but would probably be quite fragile.

On 14 November 2013 at 10:06:16 am, Johannes Wärn (warn.johan...@gmail.com) 
wrote:

I will start of with an example of what I would like to be able to write in 
Markdown.  

---  

This is a dummy paragraph, it would of course be longer than this.  

This is just another dummy paragraph; however, after it comes some pictures of 
my cat.  

http://www.example.com/pictureofmycat1.jpg  

http://www.example.com/pictureofmycat2.jpg  

http://www.example.com/animatedpictureofmycat.gif  

That was nice. Here is an audio recording of my dog barking:  

http://www.example.com/dogbark.mp3  

And finally here is a video of my two pets being cuddly:  

http://www.example.com/dogandcat.mp4  

---  

I think it’s clear that the output I am suggesting for this would be something 
along these lines:  

This is a dummy paragraph, it would of course be longer than this.  
This is just another dummy paragraph; however, after it comes some pictures 
of my cat.  
http://www.example.com/pictureofmycat1.jpg"/>  
http://www.example.com/pictureofmycat2.jpg"/>  
http://www.example.com/animatedpictureofmycat.gif"/>  
That was nice. Here is an audio recording of my dog barking:  
http://www.example.com/dogbark.mp3";>  
And finally here is a video of my two pets being cuddly:  
http://www.example.com/dogandcat.mp4";>  

I’d also say that the advantage of the syntax is clear: it’s dead simple. 
Furthermore it downgrades quite nicely.  

There are of course problems it does not solve and extra complexity it would 
introduce; however, I thought I’d write this short email to see if anyone would 
be interested in discussing the idea.  

Thank you for reading,  
Johannes Wärn  

___  
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: Excel to Markdown

[David Chambers]

Thanks for sharing this, Sherwood. I'd probably have exported a CSV and
written a Python program to do the conversions, but solving the problem
using Excel itself is a much better solution. :)


On 2 February 2014 08:33, Sherwood Botsford  wrote:

> While MMD is wonderful, much of the time you want to do other things with
> the data first.
>
> My problem:  I have a whole bunch of small tables I keep on an excel
> spreadsheet for setting my prices for various numbers of trees and whatnot.
>
>
> Here's a couple recipes for using excel data.
>
> Layout your spreadsheet as normal.
> Insert a blank row for the formating row.
> Create a wide column to the right of your table
>
> Each row corresponding to a table row has a formula something like this:
>
> "|"&A1&"|"&B1&"|"&C1...
>
> You will need to modify for possible grouping.  E.g. A one line title on a
> 5 column table will end up being
> "|"&A1&""
>
>
> In the blank cell corresponding to the formatting row, type an appropriate
> string of |::|...
>
> My problem was a bit messier than that.  I advertise on Canada kijiji (not
> the same as the US version)  They allow some formatting in ads but do not
> have a table format at all.
>
> I needed as ascii table.  The results of cut and paste from excell into a
> text processor are less than stellar, as data is separated with a single
> tab character.  Anything that lines up is coincidence.
>
> My route was to take this notion one step further, and make an ascii
> formated column that would work for either MMD or for text base ads.
>
> First attempt:
>
> "|" & A1 & REPT(" ",15-LEN(A1)) &
> "|" & B1 &...
>
> I didn't like the hard coding of the column widths.
> And if your source column is $2.50 it comes across as 2.5
>
> Second attempt.
>
> 1 blank column for column I want to use.
>
> If our table is 5 columns wide, I need another 5 columns.
>
> F1 in this one has the formula =TEXT(A1,"$0.00")
> Replicate across and down as needed.
>
> Secondly, insert a row above.  In this row, but the column width you want
> for the output.
>
> Now your formula for K2 will look like this:
> "|" & F1 & REPT(" ",K$1-LEN(F1)) &
> "|" & G1 ...
>
> At this point if I want flush right text, I have to reverse
> the REPT and the Cell reference.  No thoughts of centering.
>
> Sample output results
>
> |Bareroot Bundles of 25 2-3 year olds  
> |Bundles |# Trees   |  Cost| Price Per Tree|
> |:---|:-|-:|--:|
> |5 Trees |5 |$30.00|  $6.00|
> |Single Bundle   |25|$75.00|  $3.00|
> |5 Bundles   |125   |   $300.00|  $2.40|
> |10 Bundles  |250   |   $525.00|  $2.10|
>
>
>
> 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
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Strictdown -- My Markdown-like markup language for writing HTML documents

[David Chambers]

I suggest adding a "Differences from Markdown" section to the document.


On 11 March 2014 13:40, Jak Wings  wrote:

> Hi, everybody:
>
> I have finally finished the design of my markup language Strictdown and
> its converter written in JavaScript. :)
>
> I hope you will like it! Any feedback is welcome.
> GitHub: https://github.com/jakwings/strictdown
> Quick reference: http://jakwings.github.io/strictdown/QuickReference.html
>
> Best regards,
> Jak Wings
>
> ___
> 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: people are doing interesting stuff

[David Chambers]

I made something similar a few years ago: http://bit.ly/dXYxGU

On 13 May 2015 at 12:45, bowerbird via Markdown-Discuss <
markdown-discuss@six.pairlist.net> wrote:

>
> http://channelurl.com/show/1f8b080084a9535500037d53c1929b300cbd6726ffa09e369b21ec7d3bfd924e0f06447031166bc9c9f2f7956cd24d2fe502587ad27b4ff28ab40604971006f2f10a3e0a2664b16f963c8ec7c38fff3ec7c3f120936710fc1438f9088b4bf340f70823a5c5c92b689085120e5a1d6442c86d6a43db808b0380c131424ff1864934c94e07cf6b709bfedd2d2893931d65d56e9ebd66b6b5b7863c37c0b4a056191048ab4d2e460c3985b6a7e5dd122f206e467e2200970bf08abd1f7def42d89a12fbc898b60b4b320b34c3e8547c8eabeb67062f200457945a2b0e98c266d97f959b17cd8eda853d60ed244ba8d28bee9ab4ebe5aab4e414754cf065aebe23c9c34ba5761e08eb197e7a96b39d616054cf12b666ad2fa8f39962d8cee787ffcf1235cd8fb0512e9e5d7128149a72a205ee94c3b0870a764166a7df5e18c308a73551e7bab0154b5cea34f65aa8fbb1a9c3b34a6562051f7c9cc17574c3da63a0f8a29a5097308422b6a9c45f18166251c08c5abec3de65c6bd066bf774d3bfe4782a9c6be5d29946353d27c6a69a879fae1770ab5275fda40a5cdc8d2eb27553d441edc9a84371a0d3da2090cdb36a6da1cbeaa331d28ba12c3fb2aedff355296d4f3ad3069e9abbb8953b6067c15f27b9d882e415aaa9774af3f7a2553708877d83174b54b
>
>  
> 5b064e5daa16813606b3858b1a2f43775edabb5fc294ad5171dc9c6f1ed179c2691f5fdededdf1bf0a60bd6abe7a9c068d6d160086ddb1a3a10e9569bcf5f1352e374e20f3a6690d155c0f1f007470c58e83404
>
>
>
> people are doing interesting stuff
> ==
>
> this text (in markdown format) is stored in the u.r.l., and
> then converted and displayed when that u.r.l. is visited.
>
> that is, some code on channelurl.com:
>
> - takes the u.r.l. -- specifically, the query-string -- and
>
> - unpacks it to get the underlying markdown text,
>
> - converts it to .html, and then
>
> - displays that .html.
>
> so this text is not stored -- *does not exist* -- elsewhere.
> it is **only** in the query-string.  if you changed that, you
> would change the message itself (probably to garbage).
>
> if, when you visit the link above, you don't see all this,
> it's most likely because the listserve trashed the link.
>
> of course, this exact approach means that you cannot
> send a very long message. but it's still quite interesting.
>
> (and, of course, any form of light-markup would work;
> indeed, some might be much better suited for the job.)
>
> [try it yourself!] (http://channelurl.com/discover)
>
> ok, well... it looks like the link thingee might not work...
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: does fireball markdown support anchor links?

[David Chambers]

Yes. This is a standard part of Markdown.

On 8 July 2015 at 14:21, Alice Williams  wrote:

> Is there a way to get the same HTML anchor links like this:
>
> Link text
>
> 
>
> the gitlab version of markdown supports these links this way:
>
> [link text](#anchor)
>
> Heading 
>
> but this does not work with fireball version of markdown.
>
> thanks for any suggestions!
> Alice
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: does fireball markdown support anchor links?

[David Chambers]

You're quite right, Fletcher. Thank you for correcting me. :)

One thing to keep in mind, Alice, is that Markdown is a superset of HTML,
so one is free to write HTML in cases where there is no Markdown-specific
equivalent. Using  is an option, though not a
pretty one.

On 8 July 2015 at 15:15, Fletcher T. Penney 
wrote:

> Perhaps I misunderstood the original question, but on the chance I was
> correct….
>
>
> I think the problem is not creating the link [link text](#anchor) which is
> standard Markdown, but rather having something to link *to*.
>
>
> For example:
>
> # Heading #
>
> This will create an active link to the [heading](#heading).
>
>
> If this is what you meant, then this was something I added to
> MultiMarkdown and I imagine other implementations have also done similar
> things (and GFM is one of them).  I called them "cross-references", but I'm
> sure others called them different things as well.  In standard Markdown,
> the above link would not work, as there would not be an anchor target named
> "#heading".
>
> <http://fletcher.github.io/MultiMarkdown-4/cross-references.html>
>
>
> If I'm wrong, and David correctly understood your question then just
> ignore me….  ;)
>
>
> Fletcher
>
>
>
> --
> Fletcher T. Penney
> fletc...@fletcherpenney.net
>
> On Jul 8, 2015, at 5:49 PM, David Chambers  wrote:
>
> Yes. This is a standard part of Markdown.
>
> On 8 July 2015 at 14:21, Alice Williams  wrote:
>
>> Is there a way to get the same HTML anchor links like this:
>>
>> Link text
>>
>> 
>>
>> the gitlab version of markdown supports these links this way:
>>
>> [link text](#anchor)
>>
>> Heading 
>>
>> but this does not work with fireball version of markdown.
>>
>> thanks for any suggestions!
>> Alice
>>
>> ___
>> Markdown-Discuss mailing list
>> Markdown-Discuss@six.pairlist.net
>> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>>
>>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: does fireball markdown support anchor links?

[David Chambers]

GitHub's solution isn't ideal, as automatically generated fragment
identifiers are rather ugly in some cases. Compare the manually specified

https://github.com/plaid/sanctuary#either

to the auto-generated


https://github.com/plaid/sanctuary#either--a---c---b---c---either-a-b---c

for example.

On 8 July 2015 at 19:42, Alan Hogan  wrote:

> One final thought on the topic:
>
> If I were to pick a preferred format for auto-generated IDs, it would
> have to be hyphens. Separating words is desirable as it is more
> readable. And underscores, though not a terrible option, can be obscured
> by underlines when the entire URL is presented to a user.
>
> #section-name-like-this-preferred
>
> Of course, I've been on this list too long to expect implementations to
> actually converge on much of anything.
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

Re: Comparison of different flavors of Markdown

[David Chambers]

Here's a list of implementations:
https://github.com/markdown/markdown.github.com/wiki/Implementations

On 21 September 2015 at 07:24, Gerald Bauer  wrote:

> Hello,
>The Babelmark 2 online compare tool by John MacFarlane might be a
> good start [1]. Cheers.
>
> PS: For more links you might browse my humble awesome-markdown page [2].
>
> [1] http://johnmacfarlane.net/babelmark2
> [2] https://github.com/writekit/awesome-markdown
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss