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 smn...@gmail.com 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 smn...@gmail.com 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: 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 way...@gmail.com 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 wolfgang...@gmail.com 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 #
 !-- There can be text here, but there doesn't have to be.
--
 
   This is a codeblock.
 
 **Bold text** !-- Another comment --
 
 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:
 h1Header/h1
 
 !--
 
 
 702c6078df02d6d43aa6003f415a0408
 
 
 /blockquote
 
 
 
 46815d21b36c42e3ef8dcf757dd5758a
 
 
 
 **Bold text** !-- Another comment --
 
 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 way...@gmail.com 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: 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: 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:phi/p,version:1.9.4.2}
 
 Sorry, that should be:
 
 % curl
 % 'http://johnmacfarlane.net/cgi-bin/pandoc-dingus?text=hi+*there*'
 {html:phi emthere/em/p,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]

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: 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: 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: 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 ja...@gmx.at 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.com wrote:

 i 

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 (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]

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 dsan...@gmail.com 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