Re: Leading/trailing whitespace in inline

[Fletcher Penney]

Dan,

A few comments:


1.  Probably the best way to do this in Markdown (and variants) is exactly how 
you did it in HTML:

> perl  href="https://daringfireball.net/projects/markdown/";>Markdown.pl < 
> input.md

It's more easily understood than the alternative you use, and more amenable to 
"post-processing" of your document that could conceivable occur (e.g. "I want 
to scrape all code fragments for another use").  And it works better with CSS 
as you yourself note.

2. The only reason I see for *not* doing this is if you are looking to export 
to other formats from a single source Markdown document (e.g. LaTeX, 
OpenDocument, etc.)  If you're using Markdown.pl, that doesn't apply.

3. "Markdown the syntax" is alive and well across many spin-off projects.

4."Markdown.pl the implementation" hasn't been updated in almost 14 years (Dec 
2004 for v 1.0.1).  No new features or fixes for long-standing bugs.  You're 
unlikely to see any new releases from Gruber based on his prior public 
comments.  Based on #1 above, I would not recommend modifying Markdown.pl as 
your request, but if you insist you could do it yourself.

5. Updates and bug-fixes notwithstanding, Markdown.pl has been far surpassed by 
multiple other Markdown projects in terms of performance.  I don't recommend 
that anyone use Markdown.pl any more, except for the most trivial of use cases. 
 There are too many good alternatives out there.  (I am, of course, biased 
about which of the *Multi*ple *Markdown* implementations I would recommend 
;)   (Couldn't resist the ridiculous pun there)

6. A search of the archives 
(https://pairlist6.pair.net/pipermail/markdown-discuss/ 
) will reveal that this 
mailing list is all but dead.  You'll probably reach a few diehard Markdown 
supporters and people who simply forgot to unsubscribe.  But you may find more 
active help using the support channels specific to a particular (active) 
Markdown implementation if you don't get sufficient help here.


My $.02,

Fletcher

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

> On Aug 24, 2018, at 9:21 AM, Dan  wrote:
> 
> I'm trying to document a codebase in markdown, and finding it difficult to 
> include links inside my code examples. If I were writing HTML, I'd write:
> 
> perl  href="https://daringfireball.net/projects/markdown/";>Markdown.pl < 
> input.md
> 
> But, there doesn't seem to be a way to achieve this in Markdown, because any 
> markup i include inside backticks gets HTML encoded (as it should). The 
> closest I can do in markdown is:
> 
> `perl` [`Markdown.pl`](https://daringfireball.net/projects/markdown/) `< 
> input.md`
> 
> Which renders as
> 
> perl  href="https://daringfireball.net/projects/markdown/";>Markdown.pl
>  < input.md
> 
> but is fraught with style issues. Not only is a space a different width 
> outside , but the theme I'm using puts a background and borders on code 
> tags.
> 
> As a workaround, would you be willing to allow _DoCodeSpans to preserve 
> leading & trailing white space inside the backticks?
> 
> --- Markdown.pl.orig  2018-08-24 08:47:13.603707569 -0400
> +++ Markdown.pl   2018-08-24 08:48:46.949349781 -0400
> @@ -983,8 +983,6 @@
>   (?!`)
>   @
>   my $c = "$2";
> - $c =~ s/^[ \t]*//g; # leading whitespace
> - $c =~ s/[ \t]*$//g; # trailing whitespace
>   $c = _EncodeCode($c);
>   "$c";
>   @egsx;
> 
> With this patch, markdown like this:
> 
> `perl `[`Markdown.pl`](https://daringfireball.net/projects/markdown/)` < 
> input.md`
> 
> renders as 
> 
> perl  href="https://daringfireball.net/projects/markdown/";>Markdown.pl
>  < input.md
> 
> with the whitespace inside the  and no space between the  and 
> the , making it easier to clean up the look of the resulting webpage with 
> CSS.
> 
> Thanks very much for your time & for Markdown.
> -Dan
> ___
> 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: '_' in the middle of a word

[Fletcher Penney]

Stick around.  You'll learn.   ;)

The "official" Markdown definition doesn't really exist.  There is the syntax 
description that Gruber wrote, and the Markdown.pl implementation that he 
wrote.  Those are as close to an official definition as exists.  But according 
to his interview on [Systematic], it was not necessarily intended to be a 
completely defined syntax, and rather is intended to be a bit loose.

In either case, the perl script and syntax guide have not been updated in 6+ 
years.


F-


[Systematic]: http://5by5.tv/systematic/50

On Jul 4, 2013, at 10:47 AM, ST  wrote:

> What are the arguments of those who do not want to introduce such a
> change?
> 
> It would be nice to make a part of the official Markdown definition then
> all implementation will display this in the same way.
> 
> ST
> 
> On Thu, 2013-07-04 at 16:16 +0200, Lasar Liepins wrote:
>> On 2013-07-04, at 16:06, ST  wrote:
>> 
>>> Hi,
>>> 
>>> I recently started to use Markdown and I really enjoy it. There is only
>>> one thing that bothers me - '_' in the middle of a word. For example
>>> some_file_name.txt will display "file" italicized which is annoying. Why
>>> not to ignore all "_" which are not followed or preceded either by a
>>> whitespace or by a newline? In this way file in some_file_name.txt will
>>> not be italicized but in some _file_ name it will.
>>> 
>>> What do you think about sucha a change to Markdown?
>> 
>> it has been discussed many times. It seems that the implementations
>> are fairly split on this point. Many already ignore Underscores
>> inside words:
>> 
>> http://johnmacfarlane.net/babelmark2/?text=some_test_file.txt
>> 
>> Greetings,
>> 
>> _Lasar
>> 
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

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

Re: '_' in the middle of a word

[Fletcher Penney]

This is one of the first changes that most Markdown-derivates implement, 
including mine (MultiMarkdown).

You'll find out quickly that "Markdown.pl", the original implementation by John 
Gruber is no longer under active development, but there are many alternative 
programs to implement the Markdown syntax, or variations of it.

Fletcher

On Jul 4, 2013, at 10:06 AM, ST  wrote:

> Hi,
> 
> I recently started to use Markdown and I really enjoy it. There is only
> one thing that bothers me - '_' in the middle of a word. For example
> some_file_name.txt will display "file" italicized which is annoying. Why
> not to ignore all "_" which are not followed or preceded either by a
> whitespace or by a newline? In this way file in some_file_name.txt will
> not be italicized but in some _file_ name it will.
> 
> What do you think about sucha a change to Markdown?
> 
> Thank you,
> ST
> 
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

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

Re: Mysterious MD5ification under very specific circumstances

[Fletcher Penney]

By "markdown v.1.0.1" I'm guessing he meant Gruber's Perl Markdown.pl 1.0.1.


As for whom to report the bug, Gruber's Markdown.pl is presumably not going to 
be updated further, and has not been updated in years (also known as an 
eternity in internet time...  ;).  Certainly someone on this list may have an 
interest in finding the bug and posting a fix, but you may be better off 
switching to a variant of Markdown that is still undergoing active development. 
 As Waylan hinted, there are lots, and I'm sure everyone on the list has their 
favorites.  Heck, many people on this list have written their own (myself 
included).

When choosing a variant, some things to consider:

* What languages (if any) are you comfortable with if you want to change 
anything?  If you're not changing anything, this may not matter.

* Are you using Markdown in a larger project where the choice of language will 
have a significant impact on ease of use?

* How important is performance --- there can be several orders of magnitude 
difference between implementations?

* Do you need extensions to the basic Markdown syntax (e.g. footnotes, tables, 
etc.)?



My own implementation, for example is 
[MultiMarkdown](http://fletcherpenney.net/multimarkdown/).  It is written in C 
and is designed to compile on pretty much anything.  Once installed, you have a 
simple binary that is extremely fast and easy to use, and offers a few command 
line options.  It's easily used in shell scripts, and most languages offer the 
equivalent of a "system()" call so you can use external utilities inside of 
Perl, ruby, etc.  It offers a bunch of extra features that many believe were 
missing from the original Markdown, but you can turn those off with the 
compatibility mode to imitate the output from "standard markdown", minus most 
of the bugs.  ;)


Fletcher




On Jun 28, 2013, at 12:32 PM, Waylan Limberg  wrote:

> Wolfgang,
> 
> Which implementation of the markdown parser are you using? Perl, php, ruby, 
> python, javascript, ... (and many more) and which version specificly?
> 
> Ask to an explaination, some implementations of the parser use MD5 Hashes as 
> placeholders for the already parsed pieces of the document. My guess is that 
> you found an edge case which tripps up the code that swaps out the 
> placeholders for the parsed html.
> 
> Waylan Limberg 
> way...@gmail.com
> 
> On Jun 28, 2013 11:55 AM, "Wolfgang Faust"  wrote:
> I was building a markdown document today when my document suddenly went 
> blank. When I looked at the HTML source, I found that all my codeblocks had 
> been MD5ified. The following is a minimal document which reproduces the error:
> 
> # Header #
> 
> 
>   This is a codeblock.
> 
> **Bold text** 
> 
> In particular, there must be:
>   • A header
>   • A comment containing the sequence NEWLINE TAB followed by at least 
> two greater-than signs
>   • At least one codeblock
>   • Bold text
>   • Another comment at the end of the document.
> Changing even the smallest detail in the markdown results in a correct HTML 
> document, as expected.
> 
> When I run this through markdown v.1.0.1, I get:
> Header
> 
> 
> 
> What on earth is going on here, and who do I report this bug to?
> 
> ___
> 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


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: footnote:id, colons and jquery

[Fletcher Penney]

Discovered something similar when using MultiMarkdown to create ePubs --- the 
colon in the footnotes isn't valid (though seems to work in most readers).  
Hyphens appear to be valid characters, in that context at least.

Any reason not to switch to hyphens instead of colons?  Or could even remove 
altogether I suppose.  I would be interested in choosing something more 
compatible with other implementations rather than everyone going their own 
route.


F-


On Jan 23, 2013, at 2:29 PM, Waylan Limberg  wrote:

> 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?
> 
> [bug report]: https://github.com/waylan/Python-Markdown/issues/180
> [output]: http://michelf.ca/projects/php-markdown/extra/#fn-output
> 
> --
> 
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Community Group for Markdown Standardization

[Fletcher Penney]

(Since my opinion was asked for...  ;)


One of the last times this issue came up, I contacted the developers of a 
couple of other implementations off list to gauge their interest for such an 
undertaking.  The reception was luke warm at best.


This would be a fairly big project, if done properly.  If done improperly, it's 
simply a waste of time.  Some of the big issues/questions:

1. Is Gruber in or out?  He made his first contribution to the list in years to 
basically say that he is out.

2.  If that is true, is everyone else willing to "move past" Markdown and into 
something new.  Even if it's Markdown-like, it will probably have to use a 
different name, unless Gruber likes what he sees and changes his mind on the 
back end.  Even in that case, I think we would all be shocked if he modified 
Markdown.pl to be compliant (since it hasn't seen a change in years.)  Which 
brings us back to the beginning of how important is the Markdown "identity."  
Would it still be Markdown if the original code is non compliant?  This is a 
philosophical discussion that has real-world implications.

3. Similarly, you now have to "herd cats" and convince the developers (and 
users) of various implementations that it's worth the days (weeks?) of effort 
it might take to bring their own code into compliance.  And at the end, what do 
they have to show for it?  Old documents that no longer work as expected?

4. I don't agree with the command line switch approach that has been discussed. 
 If something like this is going to work, I think everyone needs to jump in 
with both feet.  Keep old code around for older documents (it doesn't stop 
working, after all).  But trying to maintain two separate behaviors is going to 
be more challenging -- new versions should use the new behavior.

5. The biggest danger, IMHO, is that someone puts all the time and effort into 
developing a standard, but that standard has serious conflicts with the needs 
of each Markdown-variant developer.  For example, I wrote MultiMarkdown to fit 
my needs (footnotes, tables, LaTeX, etc).  If the new standard doesn't work for 
me, why would I go through the effort to standardize?  Now repeat this 
discussion for each variant you're trying to bring into line.

6. I think we all agree that standardization, in theory, is a "good thing."  
The details will be critical in determining whether it works.

7. As for XML, LaTeX, PDF, etc --- I would suggest standardizing the plain text 
input and HTML output first.  If there is a need to standardize more than that, 
it can be handled down the road.  These are probably not worth worrying about 
now.


As for "owning" my own implementation of MD ---  MultiMarkdown was originally a 
modified version of Gruber's perl script.  MMD v3 is derived from John 
MacFarlane's excellent work on peg-markdown.   Many people have submitted bug 
reports, code patches, and suggestions that have continued to improve MMD over 
the years.  I don't know whether I "own" an implementation or not --- MMD 
represents efforts of a lot of people.  But maintaining code compatibility with 
peg-markdown may be a higher priority for me than standardization.  I hope not 
to end up in a situation where I would have to choose one over the other. 


To more concisely answer your question:

* I think standardized behavior across Markdown implementations would be good 
for everyone
* I am worried about the potential time/effort required to develop a worthwhile 
standard, and then to implement that standard
* If there was significant buy-in from the community at large, I would probably 
join in
* The new standard can't completely contradict my own goals/needs for MMD


FTP


On Nov 20, 2012, at 8:59 AM, Sherwood Botsford wrote:

> Every MD implementation would have to have two behaviours, set either
> by a command line flag, a configuration file, or a preference if used
> with a GUI.  One behaviour would be the individual behavior so that
> the followers of that implementation wouldn't be left in the lurch.
> One would be the standard behavior.
> 
> In addition some versions may have additional modes to support PDF, or
> XML or LaTeX output.
> 
> But this is NOt going to work unless you get the implementors online.
> Who, besides Mr. Fletcher owns an implementation of MD.
> 
> Fletcher, are YOU in?


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: the future of markdown, according to jeff atwood (and/or david greenspan)

[Fletcher Penney]

On Oct 25, 2012, at 11:37 PM, Sherwood Botsford wrote:

> I agree.  Since M. Gruber will neither document the fringe cases, nor take on 
> any role in the continueing development, the torch needs to pass to another.

Just to be clear - Markdown (both the perl script and the "name") are Gruber's. 
 They cannot be passed to another without his permission.

Moving on


In my ideal world, Gruber would reengage with the Markdown community to 
actually clarify some of the edge cases/inconsistencies that still exist (not 
just to claim that there are no inconsistencies), and at least add footnotes to 
the syntax (I get that he doesn't want anything else, but the footnote proposal 
was his initially)  

Perhaps he would even endorse a formal grammar specification and/or complete 
test suite.  This wouldn't be that much work (especially if he got some help), 
and would go a long way towards ensuring the continued survival of the Markdown 
brand, which will otherwise continue to remain under threat of something 
better/more consistent coming along.

IF this were to happen, I am not sure that I would see the value in creating a 
new syntax, and we could all just stick with Markdown.  This would be **much** 
less confusing for users, and would help keep Markdown's "mindshare" high.

The next best thing would a "descendent" to Markdown that shares the same 
spirit but is actively maintained.  This is not as good as option A in my 
opinion.  But if A won't happen, then is option B better than nothing?  The 
challenge, however, would be getting multiple developers (who are generally 
happy with their own implementation) to go through the effort to move to a new 
core syntax (e.g. Rockdown or whatever  as an aside, please choose a 
different name).  This has been the stumbling block when this proposal has 
come up before (both on this list and in emails between several developers with 
their own Markdown derivatives).  

For example, I am generally happy with MultiMarkdown.  What do I gain from 
rewriting it to match "Rockdown" instead of trying to match Markdown?  If only 
50% of developers make the switch, what have we accomplished?   If the Markdown 
community gets split between Markdown and Rockdown, does that just make 
something else (e.g. reStructuredText, Textile) a more attractive alternative?  
These things need to be considered before moving too far along.

> I would add a couple point to your proposal:
> 
> 6.  The initial version should be bug compatible with Gruber's MD, possibly 
> using a command line flag.  That is Rockdown --original should produce the 
> exact same HTML as GMD on the test suite.
> 
> This allows users to drop it in as a replacement, and handle the exceptions 
> one by one.

I'm not sure I follow the logic of intentionally creating bugs just for the 
sake of mimicking the very implementation we are trying to clean up.  If the 
new project is not blessed by Gruber, by definition it will be a new 
syntax/brand.  Why intentionally make it buggy?

> As a seventh point there may be merit in putting in some way to add extension 
> modules.  This way the can (hopefully) be common development on the core of 
> NarkDown (comes after Markdown.  The next one would be ParkDown) while 
> individual authors integrate multiple formats, different conventions, and so 
> on.


As I, and others, have proposed multiple times on this list before, this would 
be a necessity in some fashion.  I think there should be three "levels" of 
extensions/modules:

* The core set --- e.g. basically everything Markdown does now, with the 
possible addition of footnotes.  All implementations *must* include these to 
use the "FOO" brand.

* The "blessed" extensions --- things that basically everyone agrees should be 
in the core feature set but aren't (e.g. footnotes if not included above, and 
maybe one or two other features.)  This set should be limited, and thoroughly 
vetted (feature bloat is a tempting, but dangerous, thing).  The key, however, 
is that these features need to be implemented the same way across those 
implementations that support them.  By implementing all of these, a given 
variant could use the "FOO+" brand, or whatever.

* Optional features --- these are the additions that individual variants 
include to scratch an author's own itch and are not uniformly agreed upon (e.g. 
tables, bibliographic citations, math, etc.)  There could be a process to move 
features to the "blessed" set if they gain enough support amongst the 
community.  Developers would not be required to include these or to implement 
them in the same way across variants.  But it would be nice to centralize the 
information so that one can choose to be consistent, if desired.


My $.02,


FTP


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

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

Re: Multidingus

[Fletcher Penney]

Would it be better to use a "POST" method than a "GET" method, and keep the raw 
text out of the URL?  It seems like that is begging for trouble  Of course, 
I haven't been working as much on the HTTP/CGI stuff lately and could be 
mistaken.

Not to mention everyone will want to make sure to do some input "sanitization" 
on the text input to try to filter mischievous input.


F-

On Oct 18, 2012, at 4:32 PM, John MacFarlane wrote:

> +++ John MacFarlane [Oct 18 12 15:24 ]:
> 
>> % curl 'http://johnmacfarlane.net/cgi-bin/pandoc-dingus?text=hi *there*'
>> {"html":"hi","version":"1.9.4.2"}
> 
> Sorry, that should be:
> 
> % curl
> % 'http://johnmacfarlane.net/cgi-bin/pandoc-dingus?text=hi+*there*'
> {"html":"hi there","version":"1.9.4.2"}%
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Trouble with parentheses in Markdown hyperlinks

[Fletcher Penney]

This is really part of a larger issue, which is developing a "standards-body" 
for the community of developers of projects built around the Markdown syntax, 
now that the core program, i.e. Markdown.pl is no longer maintained.

This has been discussed multiple times on this list by myself and several 
others, and has generally not gained any traction.

I wish you luck in your quest.


F-

On Oct 18, 2012, at 1:38 PM, Andrew Pennebaker wrote:

> Could we standardize URL-parsing regexes across Markdown implementations? Can 
> we come up with a really super regex and invite the various fork developers 
> and maintainers to use that regex?
> 
> -- 
> Cheers,
> 
> Andrew Pennebaker
> www.yellosoft.us
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Trouble with parentheses in Markdown hyperlinks

[Fletcher Penney]

Don't reinvent the wheel:

http://babelmark.bobtfish.net/


F-


On Oct 17, 2012, at 10:21 PM, Andrew Pennebaker wrote:

> The big problem of a multidingus reduces to the little problems of hooking up 
> a web interface, say PHP or Rails, with a variety of Markdown parser library 
> hooks.
> 
> I fear that most of these will have to be done as backend calls, specifically 
> outputting to temporary files and echoing those to the web service. Unless a 
> majority of Markdown parsers all have PHP or Rails libs, or something.
> 
> -- 
> Cheers,
> 
> Andrew Pennebaker
> www.yellosoft.us
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Trouble with parentheses in Markdown hyperlinks

[Fletcher Penney]

I think it depends on which language is most appropriate to the situation at 
hand or is most familiar to the service's author(s) (e.g. perl, php, C, etc.) 
and which additional features are needed, if any (e.g. footnotes, tables, math, 
citations/references, etc.)

F-

On Oct 17, 2012, at 9:21 PM, Andrew Pennebaker wrote:

> Which versions of Markdown would it be reasonable to expect most services to 
> be using by now? Do we have any usage data on the various Markdown 
> implementations?


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Trouble with parentheses in Markdown hyperlinks

[Fletcher Penney]

Markdown.pl (the original implementation by John Gruber) is basically 
abandonware at this point, as it as not been updated in years.  In fact, as has 
been pointed out on this list, Gruber has not commented on this discussion 
group in years.

That said, Markdown the *syntax*, is certainly alive and well in the form of 
multiple descendant projects.

In fact, your example file below works just fine with MultiMarkdown, and 
presumably with peg-markdown (since I built MMD version 3 around John 
MacFarlane's peg-markdown implementation.)

Not sure what implementation Stack Overflow is actually using, but clearly some 
implementations work just fine in this regard.  Many (most?) modern 
implementations also have vastly improved performance over the original perl 
version for most documents (often by several orders of magnitude).  If they are 
using Markdown.pl, perhaps it is time that they upgrade  If not, simply 
speak with the developer of the actual implementation that is being used.


Fletcher



On Oct 17, 2012, at 8:50 PM, Andrew Pennebaker wrote:

> How can we improve URL detection in Markdown? I posted a question on Stack 
> Overflow and happened to click a URL in my post. To my surprise, it wasn't 
> functional, and it took three different, nonintuitive manipulations before I 
> achieved a functional URL. Stack Overflow says "not my problem", so I'm 
> deferring to Markdown itself.
> 
> Here's a sample Markdown document on Gist. All but the final hyperlink fail 
> to be functional. You can verify this behavior in Dingus. I'd paste my sample 
> directly in Gmail, but it would actually fix the URLs and obscure the problem.
> 
> I believe this is easily fixed by altering the regex responsible for parsing 
> [name](url)  syntax to be lazy rather than eager.
> 
> -- 
> Cheers,
> 
> Andrew Pennebaker
> www.yellosoft.us


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: inline link syntax question

[Fletcher Penney]

On Sep 15, 2012, at 12:47 AM, John MacFarlane wrote:

> +++ Fletcher T. Penney [Sep 12 12 18:15 ]:
>> I think a space *should* be allowed.  Some text editors seem to wrap between 
>> those characters, IIRC, which leads to problems if a space is not allowed.
>> 
>> Short of convincing argument to the contrary, I plan on keeping the optional 
>> space between the two in MultiMarkdown.  So, for selfish reasons, I would 
>> love it if you keep it in peg-markdown so I don't have to revert the change. 
>> :)
> 
> So I think there are two convincing arguments so far:
> 
> 1. The official syntax description allows the space only in
>   reference-style links, and not in inline links.

Since the "official" document and code haven't been touched in over 5 years, as 
best I can tell, and have multiple other inconsistencies and "edge cases", it's 
anyone's guess as to whether this was an intentional decision or an oversight.  
I'm not particularly convinced by this argument, since it revolves around 
guessing what was going on in Gruber's mind years ago, rather than relying on 
people who are still active in the project (or the project's offshoots, 
depending on your perspective). 

> 2. As Waylan points out, with short reference links, it's pretty easy
>   to do things like
> 
>see [link] (and by the way, blah)
> 
>   which would be parsed as links if the space were allowed.

This, in my opinion, is a much better argument.  


F-
-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: inline link syntax question

[Fletcher Penney]

On Sep 12, 2012, at 8:49 PM, Waylan Limberg wrote:

>Some text with a [link] (and some text in parentheses).
> 
>[link]: http://example.com

...

> In contrast, I can't think of any situation in normal text where a
> double set of brackets would appear except as a reference link.
> Therefore a space is not harmful. Perhaps that is why JG allowed it
> there.


Reasonable argument.  I wonder how often this happens in real life?


F-

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Definition list as image caption

[Fletcher Penney]

MultiMarkdown does the same sort of thing in version 3.


F-


On Jun 25, 2012, at 5:18 PM, John MacFarlane wrote:

> Pandoc has for some time supported the following convention.
> A paragraph containing just an image (and nothing else) gets
> treated as a figure, with the alt text as the caption.
> (If you don't want this, you can defeat it by including
> a nonbreaking space or empty comment in the paragraph alongside
> the image.)
> 
> One advantage of this extension is that it degrades well when
> you process it with standard markdown processors.
> 
> Pandoc also supports a syntax for captioning tables, described here:
> http://johnmacfarlane.net/pandoc/README.html#tables
> 
> John
> 
> +++ Lou Quillio [Jun 22 12 17:38 ]:
>> On Fri, Jun 22, 2012 at 4:00 AM, Jakob  wrote:
>>>  recently though about image captions, then i realized that this could be
>>> achiebed by Markdown Extra's definition list feature:
>>> 
>>> ![alttext](http://exampl.com/img.jpg)
>>> : here goes the *caption*
>>> 
>>> What do you think?
>> 
>> For reference, here's Russ Weakly in 2004:
>> 
>> http://www.maxdesign.com.au/articles/definition/
>> 
>> LQ
>> 
>> 
>> -- 
>> Lou Quillio
>> http://quillio.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


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Is there anyone would like to hold a standard organization of Markdown syntax?

[Fletcher Penney]

The problem is a disconnect between the effort that would be required from the 
various developers of Markdown implementations/derivatives, and the relative 
lack of benefit that they(we) would see.

For example, I am happy with how MultiMarkdown works.  There are a few minor 
tweaks I have planned after I get a few other projects finished, but in general 
it's close to "feature-complete" as far as I'm concerned.  Similarly, John 
MacFarlane is happy with how Pandoc works.  (And yes we do exchange emails 
fairly regularly...)  I imagine most other developers feel about the same - 
they eat their own dog food and they're very happy with it.


The idea of a "standards" group is not a new one.  It has been proposed on this 
very list every year or two.   And every time it is has been met with a 
resounding silence.


I recently brought up the idea of a kickstarter project with a couple of other 
developers.  The idea would be to raise financial support for the development 
and implementation of such a "standards" group.  The kickstarter idea would 
allow a gauge of community interest/support as measured by willingness to 
financially support the project.  How much would it be worth to the community 
at large for various developers to devote the several months (or more) it would 
probably take to approach this task and do it right?  Would it be enough to 
justify the time away from other (paying) projects that they would otherwise be 
working on?  What happens at the end if a system designed by committee is not 
suitable, and some (all?) of the developers decide not to implement it?

A couple of us bounced around this idea and decided that for us at least, now 
is not the right time.  In principle, we agreed that there is a theoretical 
amount of money that would balance the effort required and make this an 
attractive prospect.  But that amount is probably higher than would be 
realistic, after accounting for other projects that would have to be 
abandoned/delayed.  None of us created these projects (which are often 
open-source) because we thought they would make us rich. While all of us felt a 
passion for creating a tool that performed a specific job that we ourselves 
needed (e.g. a way to turn text into HTML that was written in Microsoft Basic), 
I suspect that none of us feels a passion for creating a committee to attempt 
to bash other developers over the head until they comply.  It's probably going 
to take some other form of a carrot; a stick is unlikely to work.


To do this right would require:

* developing and agreeing on a list of key principles (there needs to be a way 
to judge whether one proposal is "better" than another)

* developing and agreeing on a list of edge cases and how to resolve them

*  developing and agreeing on a list of extended syntax features, the "proper" 
syntax to use them, and the proper syntax for output (e.g. HTML or LaTeX, etc)

* there would have to be a way to incorporate input from the Markdown community 
at large, while remembering that if the individual developers strongly disagree 
with the results, there might be no real world implementations

* some sort of plan for a name - Markdown belongs to John Gruber, whom I 
suspect would not be involved in any of this given his longstanding absence 
from the world of Markdown.  

* some system for maintaining this going forward - who is responsible for 
fixes?  For arranging the next round 1,3,7 years from now?

* developing test suites

* "certifying" compliance amongst implementations that claim to be compliant

* etc, etc.


It's not a small undertaking.  And in the end, the developers who participate 
put in a lot of time and effort, and come away with a product that is likely to 
be a little *less* like their own vision than what they started with.  Perhaps 
you could argue that standardization might be good for allowing users to move 
from one app to another and know how things will work.  But I have that already 
- everything I do works just how I want (short of unintended bugs).  Sure, I 
sometimes wish that a web site (e.g. github) would implement more of my 
features, but those situations are fairly rare.


My suggestion for anyone who feels strongly about seeing this happen:

1) decide on the scope of what you want as a "deliverable"
2) decide on how you are going to convince developers to go along to justify 
whatever level of effort they are going to have to put in (keeping in mind that 
if the standards are developed without input from them, implementation rates 
might be low.  Getting their involvement, however, might be more expensive in 
some way - perhaps not in dollars, but in some other way
3) gather "provable" support from the community that demonstrates how #2 is 
going to be met 


I suspect that only then will such an effort as this actually move forward, and 
not just be a bunch of hot air on a list-serve.  Or maybe I'm entirely 
wrong...


F-


On May 30, 2012, at 12:52 PM, bowerb...@aol.

Re: easiest markdown to PDF conversion

[Fletcher Penney]

On Feb 27, 2012, at 9:07 PM, David Sanson wrote:

> I assume MMD composer offers a built-in way to do this, but I'm not a user, 
> so I'm not sure.

Composer doesn't currently do this directly.  The "standard" MMD approach to 
generating a PDF is via LaTeX.  The results are high quality, but they can take 
some tinkering at times.  It also requires a LaTeX installation.

Many users are perfectly satisfied with printing their HTML into a PDF.  This 
is not my approach, but I am working on way to easily integrate this into 
Composer.

In the meantime, Composer integrates well with Marked - a fantastic app for 
HTML previews, printing, styling, etc.  This is the recommended approach for 
users who want to print their HTML into a PDF.


F-


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Mac markdown editor that saves as .txt (John Laudun)

[Fletcher Penney]

On Feb 2, 2012, at 1:52 PM, Nicole C wrote:

> John, you've hit the nail on the head here.  I finally know I can manually 
> change my files to the .txt extension (thanks to helpful suggestions here), 
> but it would be excellent if MMD Composer:
> 
> a) had an option in the drop-down to save with the .txt extension, and
> 
> b) had a preference the user could set to choose the default file extension 
> for all files.


I replied in another thread that I would like to implement option b at some 
point.  But keep in mind that typing ".txt" after your file name is probably 
faster than option a.  And it works right now.  I probably won't implement 
option a.


F-

smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Mac markdown editor that saves as .txt

[Fletcher Penney]

On Feb 2, 2012, at 1:49 PM, Nicole C wrote:

> Fletcher:  Your post was a mini-revelation for me!  I had assumed that 
> Composer (and similar apps) required the special markdown file extensions in 
> order to utilize all of their features.  I didn't realize that manually 
> entering .txt instead of the default would work just fine.  Thank you!  This 
> essentially solves my problem.  I'll also experiment with customizing the 
> syntax coloring.  

Glad that helped - it is a few extra keystrokes to enter the ".txt", but it's 
available right away.  I'll look into a user preference for file extension, but 
that might take a little while for me to get to.

> I really do like MMD Composer and think the syntax coloring options are more 
> attractive than most out there.  The one thing I do like about ByWord's 
> coloring that would be nice as an option in Composer (just an option, not 
> default) is the immediate greying-out of the code marks while retaining the 
> stylized text (bolded, italicized, etc.)  It makes your text very readable 
> for certain projects.  But I think I could achieve much the same thing with 
> some creative CSS editing, if I can manage it.

I have thought about the option to "dim" code marks, as you call them.  It 
would require rewriting much of the PEG for the highlighter, but it's not 
impossible.  It's not first on my list of priorities, however, so I can't 
promise if/when it will be completed.  I'm actually trying to come up with a 
totally different approach to the underlying code, which might offer additional 
flexibility and performance (I hope.).

> Spencer: I'm curious about the markdown bundle for Textmate, but you're 
> right, it's not a cheap program.  What sort of neat things does the bundle do?

There is a MultiMarkdown derivative of the Markdown bundle for TextMate that 
adds some MMD related features.  Because of my work on Composer, it's no longer 
under active development by me, but it's still on GitHub and available for 
hacking away on.  


F- 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Mac markdown editor that saves as .txt

[Fletcher Penney]

Not sure I follow - Composer saves files in plain text, and you can use 
whatever file extension you like.

And you don't have to use the default theme with solarized colors if you want a 
less colorful editor window.


What does it not do in this regard that you are looking for?


Fletcher


-- 
Fletcher T. Penney
fletc...@fletcherpenney.net 

On Feb 1, 2012, at 6:48 PM, Nicole C wrote:

> So, are there any markdown editors for the Mac that do all the "pretty" 
> things (receding the code, stylizing your text, etc) but that DON'T save as 
> .md or .markdown files?  Am I correct that Macchiato only saves in markdown 
> format?  I'd even take something like MMD Composer, with its colorized & 
> stylized text, if it saved in plain text format. 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Metadata syntax (was Universal syntax for Markdown)

[Fletcher Penney]

Side note - the actual Hamlet line has a colon at the end of the line.
So it would be fine in MMD.

;)

F

Sent from my iPhone

On Sep 19, 2011, at 10:30 AM, David Sanson  wrote:

> The reStructuredText field list syntax might be a reasonable compromise.
>
> I like the fact that the metadata can occur anywhere in the document.
>
> The [RST spec][] itself says that the leading colon can be dropped "in
> well-defined contexts such as when a field list invariably occurs at
> the beginning of a document (PEPs and email messages)." As John's
> example from Hamlet shows, this isn't the case for markdown documents.
> But it would be possible to grandfather in existing MMD documents by
> insisting, as MMD does, that first lines that contain a colon are
> unambiguously metadata, with apologies to Hamlet. Or one could
> introduce a delimiter, like `--`, and say that lines before that
> delimiter are unambiguously metadata, and so don't require the leading
> colon.
>
> Frankly, I don't think it wouldn't be a terrible thing if
> implementations disagreed on this one detail---when is a leading colon
> required?---but agreed on everything else. Those who wish to trade
> flexibility for beauty could leave off the leading colon; those who
> value inter-operability over beauty could leave it on.
>
> David
>
> [RST spec]: 
> http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists
> ___
> 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