doesn't that make you wonder?
aristotle pagaltzis said:
>we can agree he has achieved more in three months
>than you have in a decade of talking.
i'm not sure who your "we" is, aristotle, but i guess this means
that you will not be doing alpha-testing for my new program...
how will i ever be able to manage without your valuable input?
***
but hey, maybe i'm wrong, and this list _has_ accomplished
something worthwhile and notable in the last three years...
if you believe it has, do please feel free to tell us what it was.
***
on the other side of the fence, however, i see lots and lots of
people who are doing things with markdown these days, but
only a very precious few even bother to come here and _tell_
this list what they are doing (and usually well after the fact),
and nobody -- and i mean absolutely nobody -- comes here
for _advice_ or "accumulated wisdom" or _anything_ like that.
heck, even _gruber_ doesn't bother to come here any more...
doesn't that make any of you people _wonder_?
***
emmanuel said:
>I made a Markdown editor webapp two weeks ago:
>http://akaya.me ("Yet Another Markdown Editor")
you've made a nice start, emmanuel, a nice start indeed.
here is my review of "the good, the bad, and the ugly"...
***
we'll start with the "good" section...
as far as the "good" goes, i like that you've made a web-app.
it's time to put the script-kiddies to bed; if installing a script
is part of your workflow, the general public will never buy it...
and the way your app is taking care of "file management" is
in tune with how the trend seems to be heading these days...
moreover, the "yet another" name shows that you realize that
what you've done might be one in a big number of contenders;
it's good to have healthy expectations even if you dream big...
finally, you've made an improvement in the achilles' heel of
_every_other_ on-the-fly converter, as far as i know, which is
that they don't show the point which is being actively edited.
except for this last point, all of the items in your "good" list
are mirror-imaged in the "bad" category, which is _curious_...
***
so here's the "bad" section...
first, the web-app part. it is _good_ to have a web-app, but
it would be better if you had a combination of offline/online.
i understand the benefits of having something in the browser.
but native apps still have advantages, and likely always will...
the only approach i see prevailing long-term will _use_both_.
on "file management", i guess i'm old-fashioned, but i want to
know where the file is, be able to do direct manipulation on it,
edit it in another app, run my own spellcheck tools on it, etc.
i see where i can "download" the markdown file, but that would
then just be a copy of the actual "file", not the document itself.
i'm also unclear on where the actual "file" resides. is it in the
offline cache for that specific browser? -- in which case even
another browser on my own machine won't be able to get to it?
as there's no log-in, it can't be stored "in the cloud", meaning
that i certainly cannot get to it while using another _machine_,
thus removing a lot of the functionality of having a web-app...
confusions like these are gonna lose the average user quickly.
this brings us to the thing about having lots of "competitors"...
i fully realize you might just be doing this project "for fun" and
not have aspirations of making it "big"... but, at the same time,
you obviously know that a developer must do serious polishing
in order to take any project public in the way that you are doing.
having a base of users is what can make all that work worthwhile.
so you need to ask questions about what could make users come
to prefer your site over all of the other competing sites instead...
i don't have any answers; just telling you those are the questions.
as far as those "competitors" go these days, in my eyes you have
_two_ in particular that you'll need to stack yourself up against...
and no, google docs isn't one of them.:+)
(people looking for a web-based editor should most certainly
consider google docs. and they will do so, i am quite sure, but
if google docs makes 'em happy, no peons like us can compete.
we're splitting whatever scraps might fall off the google table,
as well as people who refuse to eat at that table on principle.)
and no, i don't consider all the other online-editing sites now
cropping up to be "your competition" either. on the one hand,
yes, of course they are. on the other hand, they are equivalent
to you, so there's no real good reason to prefer them over you.
not at the present time, anyway...
i feel much the same about all the ipad editing apps. they show
great promise, and the might be competitors to you long-term,
but for the here-and-now, they'll still have to prove themselves.
so as far as i can see, your competition is "marked.app" and the
still-forthcoming-but-any-day-now "multimarkdown composer".
and yeah, both of those are offline entities, so you
Re: doesn't that make you wonder?
* bowerb...@aol.com [2011-10-16 21:40]: > how will i ever be able to manage without your valuable input? You don’t need it. You’ll take the world by storm same as you did the last five times you created a revolution. With or without my participation, the outcome won’t differ. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
Many thanks for your input. Answers below. 2011/10/16 : > so here's the "bad" section... > > it would be better if you had a combination of offline/online. > the only approach i see prevailing long-term will _use_both_. The goal is for this app to run offline; it's actually pretty easy to do but will only work with recent browsers. In fact, I'm thinking of making it a Chrome app (that would therefore only work in Chrome), which would solve a lot of problems, including offline mode and file management issues; the Chrome browser is available for all platforms but there are corporate entities that flat-out refuse to use it, so I'm not sure about this yet, but this is where I'd like to go. Once I figure out if I go the Chrome route or not, I'll add offline capabilities. > on "file management", i guess i'm old-fashioned, but i want to > know where the file is, be able to do direct manipulation on it, > edit it in another app, run my own spellcheck tools on it, etc. > i see where i can "download" the markdown file, but that would > then just be a copy of the actual "file", not the document itself. > i'm also unclear on where the actual "file" resides. is it in the > offline cache for that specific browser? Yes (localstorage). > -- in which case even > another browser on my own machine won't be able to get to it? > as there's no log-in, it can't be stored "in the cloud", meaning > that i certainly cannot get to it while using another _machine_, > thus removing a lot of the functionality of having a web-app... > confusions like these are gonna lose the average user quickly. It's also stored in the "cloud" (the cloud being the server that serves the app). There's "invisible" login: the first time you access the app you're given a unique ID that is used to identify your documents (this id is used in the documents' names when you download them). For now the UI doesn't exist to download files to another browser, but all the infrastructure is in place. If the app were a Chrome app it would be easier because Chrome would automatically sync localstorage without the user having to do anything (and still not have to login!); that would be a big gain I think. There's another "problem", though. I devised a "proprietary" file format, which stores files as lists of diffs with a timestamp, so that you can undo any change, even months later (the changes are right there in the file and are never deleted). The undo functionality is not coded in the UI yet. But that means that the "raw" file is not usable by the user as-is, nor is it usable by another program (although the diffs are stored in common diff notation). It's a simple format but it's proprietary and new: that's the bad part. I need to figure out if the good part (being able to do infinite undos) offsets the bad part (having a special file format). I could also interface with Dropbox (I probably will); what I don't want is to depend on Dropbox: to force users of my app have a Dropbox account. > so as far as i can see, your competition is "marked.app" and the > still-forthcoming-but-any-day-now "multimarkdown composer". They're both fantastic, but Mac-only, so I believe that leaves a big part of the corporate world still open? (Although it's possible that companies that know of Markdown, use Macs, and companies who use PCs have never heard of it. ;-) But the real innovation here, IMHO, is marked.app, which lets the user choose her editor of choice; that's really great. MultiMarkdown Composer, on the other hand, is less impressive: AFAIK it doesn't do anything that a webapp couldn't do, so why download an app that will only work on a specific platform? > finally, we have your innovation -- showing the particular part > actually being actively edited by the person at the current time. > > all the online converters show the .html starting at _the_top_, > which is not what you want when you doing mid-doc editing, > and this is the improvement which you brought, emmanuel... That's actually what got me started to build this; I found all the other webapps unusable after the first few paragraphs... > (which, for the record, is not to say the solution was difficult. > i worked it out for my program. it does get a bit problematic > when -- like "marked" -- you can't track the insertion point; > but even then, the secret isn't that hard to figure out, so i am > somewhat surprised that brett has not puzzled it out already. > he'd simply have to save each version of the text in a variable, > then compare it to the text the next time it is to be converted; > the first point of difference is where he should focus display.) That's not how I do it, because I need the current paragraph to be highlighted when clicked on (ie, in the absence of any kind of change). But I did try your approach first, and found out that you need to detect changes in the resulting HTML, not the source Markdown. For example, if you're editing a link by reference, you want to see in t
Re: doesn't that make you wonder?
+++ Emmanuel Bégué [Oct 17 11 11:06 ]: > [But is it really true that there are inconsistent results for what > may be called "Core Markdown" (as described in the original Gruber > posts)?] Yes, many. Gruber's informal syntax description underdescribes the syntax, and different implementations have resolved ambiguities differently. So, for example, the official syntax description says that asterisks and underscores indicate emphasis. But it doesn't give clear rules about nesting. Consider, for example, this input: *test **test* test** discount and sundown render it as: test **test test** PHP markdown, peg-markdown/multimarkdown, pandoc, and lunamark render it as: *test test* test maruku renders it as: testtest test** Markdown.pl is not a good guide, since it gives invalid HTML on this input: test test test The other renderings could all be defended on the basis of the syntax description. It simply isn't explicit enough. It's easy to come up with other cases where different implementations vary, e.g. [hi `there](/url)` The markdown syntax description doesn't say whether [ or ` takes precedence. Discount, sundown, and lunamark let the [ take precedence, while PHP markdown, peg-markdown, multimarkdown, and pandoc let the ` take precedence. Both decisions are defensible, I think. Markdown.pl lets the ` take precedence, but nothing in the syntax description says this is the way to go, and as noted above, Markdown.pl cannot be counted on for reliable guidance. These cases are unlikely to occur in real documents, but there are other differences that come up quite frequently. So, some implementations (e.g. pandoc, lunamark, peg-markdown, multimarkdown) require sublists to be indented four spaces, while others (e.g. discount, sundown, Markdown.pl, PHP markdown) do not. I have argued before on this list that the "four space rule" is implicit in the markdown syntax specification. But it's not quite explicit, hence the trouble. So you may find that what is a nested list on one markdown implementation is a single-level list on another. I made the case long ago that there should be a formal grammar for markdown, but the idea was never popular on this list. I wrote peg-markdown and lunamark to show that a formal specification was possible. Not everyone will agree with the way these grammars resolve ambiguities in the spec. And some may think that instead of a formal grammar, we need an official parsing algorithm (such as HTML 5 has). But until there is some kind of agreed-upon formal specification, implementations will inevitably diverge, even on "core" syntax. John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
On 18 Oct 2011, at 01:47, John MacFarlane wrote: > […] I have argued before on this list that the "four space rule" is implicit > in the markdown syntax specification. But it's not quite explicit, hence the > trouble. Maybe I am misunderstanding your reference but the specification¹ seems fairly explicit: | List items may consist of multiple paragraphs. | Each subsequent paragraph in a list item must | be indented by either 4 spaces or one tab ¹ http://daringfireball.net/projects/markdown/syntax#list > So you may find that what is a nested list on one markdown > implementation is a single-level list on another. Adding to that, whether or not the list items are wrapped with . > I made the case long ago that there should be a formal grammar for markdown, > but the idea was never popular on this list. I think there are many who would like to see a formal/exhaustive specification, and no-one can be happy about say, text editor syntax highlight doing it one way, the local preview showing it another, and when posting the document online, yet another interpretation is applied. The problem is partly that several want it to be about the user, so it doesn’t matter there are 30 lines of code to try and guess what the user meant, rather than have the user be more explicit (it is after all meant as sort of an anti-markup language). Another problem is that the majority of Markdown.pl derivatives are implemented as a long series of global substitutions running on the full document — this is far from a “real” parser so the maintainers will have to start from scratch, and it’s unlikely they can provide 100% backwards compatibiity for their flavor of markdown, leading to close to no uptake. If we want a formal specification, I think the best approach is a clean break from markdown. There are anyway stuff which is actually in the current specification, which for me is quite a gotcha, like lazy-mode for nested block quotes (so decreasing quote level has the higher level persist). I’ve been contemplating this for a while, but with the current situation being fine most of the time for most of the people, it’s one of those cases where it’s hard to really justify the effort that goes into trying to change things. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
+++ Allan Odgaard [Oct 18 11 10:10 ]: > On 18 Oct 2011, at 01:47, John MacFarlane wrote: > > > […] I have argued before on this list that the "four space rule" is > > implicit in the markdown syntax specification. But it's not quite explicit, > > hence the trouble. > > Maybe I am misunderstanding your reference but the specification¹ seems > fairly explicit: > > | List items may consist of multiple paragraphs. > | Each subsequent paragraph in a list item must > | be indented by either 4 spaces or one tab This concerns multi-paragraph list items: - first paragraph of list item second paragraph of same list item I was talking about nested lists: - item - subitem Some implementations require "- subitem" to be indented four spaces, while others allow three space indentation. (Incidentally, I first noticed this when I saw nested lists indented three spaces in an early version of the TextMate manual; I then confirmed that Markdown.pl treated these as nested lists, contrary to the impression I'd formed from the syntax specification.) One could argue that the nested list counts as a "subsequent paragraph," in which case the passage you quoted from the spec settles the issue. I wouldn't say that's obvious, though. Interestingly, the syntax description for lists doesn't say anything about nested lists. It does say explicitly how to include a code block and a block quotation under list items, but it says nothing about how you include another list under a list item. Since other block elements need to be indented four spaces to be included under a list item, it seems reasonable that lists do too, but that isn't said explicitly. > > So you may find that what is a nested list on one markdown > > implementation is a single-level list on another. > > Adding to that, whether or not the list items are wrapped with . > > > I made the case long ago that there should be a formal grammar for > > markdown, but the idea was never popular on this list. > > I think there are many who would like to see a formal/exhaustive > specification, and no-one can be happy about say, text editor syntax > highlight doing it one way, the local preview showing it another, and when > posting the document online, yet another interpretation is applied. > > The problem is partly that several want it to be about the user, so it > doesn’t matter there are 30 lines of code to try and guess what the user > meant, rather than have the user be more explicit (it is after all meant as > sort of an anti-markup language). This is an interesting difference between markdown and reStructuredText, by the way. On the reStructuredText mailing list, one often finds proposals rejected with the words "Too implicit." But there isn't really an incompatibility between formal specification and "trying to guess what the user meant" -- it just means that the formal specification is going to be more complicated. That said, if I were designing a "non-markup" language from scratch, there are many things I'd do differently. I think there's an unoccupied sweet spot somewhere between markdown and reStructuredText. John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
2011/10/18 John MacFarlane : > I made the case long ago that there should be a formal grammar for > markdown, but the idea was never popular on this list. I wrote > peg-markdown and lunamark to show that a formal specification was > possible. Not everyone will agree with the way these grammars resolve > ambiguities in the spec. And some may think that instead of a formal > grammar, we need an official parsing algorithm (such as HTML 5 has). > But until there is some kind of agreed-upon formal specification, > implementations will inevitably diverge, even on "core" syntax. Thanks for this detailed answer. There are two solutions to this problem: the "official" one (either an official spec or even a reference implementation) or the "de facto" one (a specific implementation that "wins"). The official approach needs authority to establish itself, which is difficult to find; since Gruber himself [does not really seem to care](http://www.codinghorror.com/blog/2009/12/responsible-open-source-code-parenting.html), it's unclear where this authority could come from (consensus is a poor substitute for authority). But it's also not certain that the official approach would solve all problems. The first example you gave (*test **test* test**) is "invalid Markdown" and a formal specification could very well decide that implementations are free to deal with invalid input any way they choose (either by trying to fix it silently, in some way or another*, or by raising an error). And so it's possible that the best course of action is to wait for a specific implementation to gain so much traction that every other implementation that doesn't behave in the same way, looks broken. In the meantime, maybe tools should advertise more clearly what underlying implementation they rely on, and implementations themselves, somehow document their behavior on all ambiguous points...? Does a list of those ambiguities even exist? Regards, EB *: why not test test test for example? ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
On 2011-10-19 12:04 +0200 Emmanuel Bégué wrote: > In the meantime, maybe tools should advertise more clearly what > underlying implementation they rely on, and implementations > themselves, somehow document their behavior on all ambiguous > points...? Does a list of those ambiguities even exist? Regarding documenting the behavior of the implementation (parser/emitter) in case of ambiguities, see for example http://kramdown.rubyforge.org/syntax.html where I tried to document how the kramdown parser does work in general and in case of ambiguities. Best regards, Thomas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
+++ Emmanuel Bégué [Oct 19 11 12:04 ]: > But it's also not certain that the official approach would solve all > problems. The first example you gave (*test **test* test**) is > "invalid Markdown" and a formal specification could very well decide I don't think there's any such thing as "invalid Markdown." At any rate, the syntax description does not define anything as "invalid". And markdown processors (at least those that I'm familiar with) don't ever give you an "invalid markdown" error. But if you don't like that example, consider this one: ***hello*** Should this be hello or hello ? Nothing in the spec settles that. This is just one of many, many examples one can come up with by considering precedence ambiguities. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
Not a great example, as strong and emphasis are commutative tags. Wait. I take that back. With CSS styling, they would not commute if both CSS styles defined some of the same attributes. E.g. If strong was defined as color:pink and emphasis was defined as color:green, they would no longer commute. Previously on this topic, the discussion turned to how to unify things. Since we have no Authority, then building Concensus is what remains. Does anyone have a ranking of MD variants by either pages or number of users? Would it be possible if not to come to a single MD spec, to at least reduce the number of specifications. E.g. Suppose that Fletcher is open minded, and eager for consolidation. Further suppose that MMD is the #4 variant. He contacts #1,2,3, and 5, and asks if as a group they can agree on a spec. #2 says, stuffit, but 1,3 and 5 agree. They get together, and modify the code. Each introduces a flag, "-new" to the command line (or preferences for apps) to support the new syntax during the transition period. Later on -new will be the default behaviour, and -traditional is used for the current behaviour. If agreement is reached, then the group looks at variants 6,7,8,9 and inquires if they would like to join in this effort. Part 2. Has anyone collected a would-be canonical list of either the ambiguous cases in original MD, or the variants between the versions of MD? Respectfully, Sherwood of Sherwood's Forests Sherwood Botsford Sherwood's Forests -- http://Sherwoods-Forests.com 780-848-2548 50042 Range Rd 31 Warburg, Alberta T0C 2T0 On Wed, Oct 19, 2011 at 4:33 PM, John MacFarlane wrote: > +++ Emmanuel Bégué [Oct 19 11 12:04 ]: > > > But it's also not certain that the official approach would solve all > > problems. The first example you gave (*test **test* test**) is > > "invalid Markdown" and a formal specification could very well decide > > I don't think there's any such thing as "invalid Markdown." > At any rate, the syntax description does not define anything as > "invalid". And markdown processors (at least those that I'm > familiar with) don't ever give you an "invalid markdown" error. > > But if you don't like that example, consider this one: > > ***hello*** > > Should this be > > hello > > or > > hello ? > > Nothing in the spec settles that. This is just one of many, many > examples one can come up with by considering precedence ambiguities. > > ___ > 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: doesn't that make you wonder?
Yay, a plan, I like it! I have no authority over even any project or code, but I have dabbled in MarkdownDeep, and would be very happy to help align it with anything that came out of this consensus! Thanks, Tao From: markdown-discuss-boun...@six.pairlist.net [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Sherwood Botsford Sent: Thursday, October 20, 2011 9:21 AM To: Discussion related to Markdown. Subject: Re: doesn't that make you wonder? Not a great example, as strong and emphasis are commutative tags. Wait. I take that back. With CSS styling, they would not commute if both CSS styles defined some of the same attributes. E.g. If strong was defined as color:pink and emphasis was defined as color:green, they would no longer commute. Previously on this topic, the discussion turned to how to unify things. Since we have no Authority, then building Concensus is what remains. Does anyone have a ranking of MD variants by either pages or number of users? Would it be possible if not to come to a single MD spec, to at least reduce the number of specifications. E.g. Suppose that Fletcher is open minded, and eager for consolidation. Further suppose that MMD is the #4 variant. He contacts #1,2,3, and 5, and asks if as a group they can agree on a spec. #2 says, stuffit, but 1,3 and 5 agree. They get together, and modify the code. Each introduces a flag, "-new" to the command line (or preferences for apps) to support the new syntax during the transition period. Later on -new will be the default behaviour, and -traditional is used for the current behaviour. If agreement is reached, then the group looks at variants 6,7,8,9 and inquires if they would like to join in this effort. Part 2. Has anyone collected a would-be canonical list of either the ambiguous cases in original MD, or the variants between the versions of MD? Respectfully, Sherwood of Sherwood's Forests Sherwood Botsford Sherwood's Forests -- http://Sherwoods-Forests.com 780-848-2548 50042 Range Rd 31 Warburg, Alberta T0C 2T0 On Wed, Oct 19, 2011 at 4:33 PM, John MacFarlane wrote: +++ Emmanuel Bégué [Oct 19 11 12:04 ]: > But it's also not certain that the official approach would solve all > problems. The first example you gave (*test **test* test**) is > "invalid Markdown" and a formal specification could very well decide I don't think there's any such thing as "invalid Markdown." At any rate, the syntax description does not define anything as "invalid". And markdown processors (at least those that I'm familiar with) don't ever give you an "invalid markdown" error. But if you don't like that example, consider this one: ***hello*** Should this be hello or hello ? Nothing in the spec settles that. This is just one of many, many examples one can come up with by considering precedence ambiguities. ___ 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: doesn't that make you wonder?
2011/10/20 John MacFarlane : > I don't think there's any such thing as "invalid Markdown." You're right, and I misspoke: part of the beauty of Markdown is that "anything goes" -- but it's also what makes it hard! Regards, EB ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
On 20 Oct 2011, at 15:20, Sherwood Botsford wrote: > […] If agreement is reached, then the group looks at variants 6,7,8,9 and > inquires if they would like to join in this effort. On 19 Oct 2011, at 02:27, John MacFarlane wrote: > That said, if I were designing a "non-markup" language from scratch, there are > many things I'd do differently. I think there's an unoccupied sweet > spot somewhere between markdown and reStructuredText. I’d be much more interested in hearing what John has in mind. I’m not optimistic about “fixing” the Markdown situation and I see little point in providing a migration path. Take e.g. GitHub, they offer Markdown as one choice for their wikis, READMEs, etc. — you think a) they’ll update their C code to new strict rules that “we” agree on (and tell them to conform to, mind you, they already have their own flavor of Markdown) and b) have all existing Markdown text on GitHub updated to be compatible with the updated rules? I see a bigger chance of filling the niche between Markdown and reStructuredText that John was alluding to, getting traction, and then see that as a new format added to their wiki (it already has several), and understood when READMEs have the proper extension. Then we can also finally mandate a file extension: I suggest calling the new format “Markright” with “.mr” as file extension :) ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
2011/10/20 Sherwood Botsford : > > Has anyone collected a would-be canonical list of either the ambiguous cases > in original MD, or the variants between the versions of MD? This inventory is a necessary first step. It can be very tedious to build a spreadsheet of ambiguous cases X implementations X versions, but it could be automated with a test document? The test document would list ambiguous cases with unique "IDs", that could then be automatically extracted from each resulting transform, to record the behavior of each implementation on each test (existing... or future implementations, and their versions). (If and when a consensus is reached, the same test document (or test suite) could be used to check for conformance). Regards, EB ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
On Oct 20, 2011, at 6:20 AM, Sherwood Botsford wrote: > Not a great example, as strong and emphasis are commutative tags. > > Wait. > > I take that back. With CSS styling, they would not commute if both CSS > styles defined some of the same attributes. E.g. If strong was defined as > color:pink and emphasis was defined as color:green, they would no longer > commute. Right. And you could also have CSS rules defined for emph > strong and/or strong > emph ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
My "official" stance is: 1) I think consolidation is a good idea 2) consolidation is going to take time and effort 3) those of us who have written our own variants are probably happy with how they work (or else we would have changed them already) 4) These developers, as individuals, might not actually see much benefit from the time and effort it takes to standardize on something that, almost by definition, will be less close to our own "ideal" markup than what we've already written 5) Therefore, I think it's going to take some other purpose/benefit/reward to help motivate the group to work on this. That doesn't mean it's not a worthy goal --- just that it's going to take some dedication. And as I've stated here before, it's going to take a clear, well-defined "mission statement" to help guide the effort. Inevitably, some people will fall into the "kitchen sink" camp and will want every conceivable feature. Others, like myself, will prefer the smallest number of features necessary to accomplish the needs of most (but not all) users. Without a clear mission statement, resolving these sorts of disputes will be impossible. Personally, I found John MacFarlane's peg-markdown to be a very compelling program conceptually, and in its implementation. The idea of a parsing expression grammar (PEG) that could be reused for other purposes was intriguing (though I had no idea what it was when I read about it...) Moving MMD from perl to the PEG/C combo took several months of effort, and required some changes to the MMD syntax. But I feel like in the end I was left with a program that was faster, more accurate, more useful, and more compatible. Additionally, I was able to take that PEG and with minimal modifications use it as the basis for the highlighter in MMD Composer. I could never have done that with the perl script. And with the PEG, I know that both apps will interpret the source in the same manner (aside from any bugs I may have introduced in the migration). And any other developer that wants to implement MMD in another language/environment/OS/whatever, can use that PEG to ensure that their version of the MMD syntax matches mine. I didn't always agree with every decision John made in defining the PEG for peg-markdown (which forms the basis for peg-multimarkdown/MMD 3.0). But he always had well thought out, well articulated, reasons for his approach. He was very accommodating when I proposed changes, and was quick to fix bugs. Agreeing to go with his interpretation was rarely a huge sacrifice, and the benefits far outweighed any downside for me. As a thought experiment, consider this perspective (some of which may be true, some of it isn't true): * MultiMarkdown suits my purposes quite well - I can create presentations for lectures, formal letters on custom letterhead, I run several web sites with it... There's very little in the sphere of writing that it can't do for me. * I now have a GUI editor that "understands" MMD natively. * There's not a popular text editing tool/app that I'm aware of (for the Mac at least) that does not have requests out there asking for them to support MMD. That doesn't mean anyone will do anything about it, but the requests are out there. * Other developers are asking me about how to incorporate MMD (and some, like Daniel Jalkut, have actively contributed to making that possible!) * More and more apps *are* supporting MMD natively, in some fashion or another * I expect those numbers to grow now that MMD is a C program/library, and when I clean it up enough to be easier for developers to use, I suspect it will grow even faster * I can change MMD any time I get a new itch that it doesn't already scratch --- I don't have to wait on anyone, or worse, a committee of anyones * I'm already busy maintaining MMD, responding to questions/support issues, and now about to start selling a commercial app built around MMD --- the last thing I need is to give myself more work that might not show me much benefit * So, in my world, MMD is the #1, #2, and #3 variant. (Not to say that is true for anyone else, just for me) So given these statements (again, some I agree with, some not, but I could see other hypothetical developers in this situation citing them) --- convince me that an effort to "standardize" would be worth my time and effort? What benefit am I going to see that justifies several more months (years?) redoing my work? Another part of this thread mentioned that perhaps there was a sweet spot between Markdown and reStructuredText that was ripe for development. That may be true, and if anyone pursues it, I wish them all the best. But for me, and I suspect others, I don't *want* something much more formal or complicated than MD/MMD. That's why I like MD. What I *do* want is a more standardized approach to interpreting the Markdown syntax. My guess is that most users don't care which interpretation
RE: doesn't that make you wonder?
OK, I interpret this (besides the quite-reasonable "why should I care?" vibe), combined with previous references to the PEG grammar(s) implicit in MultiMarkdown and peg-markdown's implementations, as "a formal specification already exists". That sounds fine - I'd love to use peg-(multi)markdown in my programs, but I see two practical problems for that right now: . A C library, while portable to any processor architecture, if not portable to any development environment, and certainly not future-proof. I, personally, would like to be able to rely on the exact same syntax not only across the OSs that Fletcher mentions, but also in C# code (that can be sandboxed safely - no P/Invoke calls to unsafe code) and also in browsers. There are numerous other environments (Java, etc) where a similar "safe code" requirement precludes the use of a C library (at least in browser and other high-sandboxing environments). . The PEG grammars(s) may be formal reproducible reusable specifications, but my understanding is that they are not so meaningful without a definition of what they map to. If my brief reading on this is correct, a PEG grammar allows you to define behaviours to be executed upon encountering certain source structures; those behaviours implement a conversion to HTML, or latex, or whatever, but are implicit in the Program, not the Specification/Grammar So if we take the current PEG-based implementations as a starting point, what would it take to produce a specification that formally establishes not only the source structures to be matched, but also the behaviour/conversions to be implemented against them? Is this just a question of detailed documentation and an open test-suite? Another applicable question is: are PEG grammars easily usable in other environments? A brief search suggests so (js: http://stackoverflow.com/questions/79584/are-there-any-parsing-expression-gr ammar-peg-libraries-for-javascript-or-php, C#: http://www.codeproject.com/KB/recipes/grammar_support_1.aspx not GPL-compatible, sadly.); does anyone know how fesible it is to take the existing PEG grammar(s) and reuse them in other languages? Thanks, Tao From: markdown-discuss-boun...@six.pairlist.net [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Fletcher T. Penney Sent: Thursday, October 20, 2011 12:28 PM To: Discussion related to Markdown. Subject: Re: doesn't that make you wonder? My "official" stance is: 1) I think consolidation is a good idea 2) consolidation is going to take time and effort 3) those of us who have written our own variants are probably happy with how they work (or else we would have changed them already) 4) These developers, as individuals, might not actually see much benefit from the time and effort it takes to standardize on something that, almost by definition, will be less close to our own "ideal" markup than what we've already written 5) Therefore, I think it's going to take some other purpose/benefit/reward to help motivate the group to work on this. That doesn't mean it's not a worthy goal --- just that it's going to take some dedication. And as I've stated here before, it's going to take a clear, well-defined "mission statement" to help guide the effort. Inevitably, some people will fall into the "kitchen sink" camp and will want every conceivable feature. Others, like myself, will prefer the smallest number of features necessary to accomplish the needs of most (but not all) users. Without a clear mission statement, resolving these sorts of disputes will be impossible. Personally, I found John MacFarlane's peg-markdown to be a very compelling program conceptually, and in its implementation. The idea of a parsing expression grammar (PEG) that could be reused for other purposes was intriguing (though I had no idea what it was when I read about it...) Moving MMD from perl to the PEG/C combo took several months of effort, and required some changes to the MMD syntax. But I feel like in the end I was left with a program that was faster, more accurate, more useful, and more compatible. Additionally, I was able to take that PEG and with minimal modifications use it as the basis for the highlighter in MMD Composer. I could never have done that with the perl script. And with the PEG, I know that both apps will interpret the source in the same manner (aside from any bugs I may have introduced in the migration). And any other developer that wants to implement MMD in another language/environment/OS/whatever, can use that PEG to ensure that their version of the MMD syntax matches mine. I didn't always agree with every decision John made in defining the PEG for peg-markdown (which forms the basis for peg-multimarkdown/MMD 3.0). But he always had well thought out, well articulated
Re: doesn't that make you wonder?
On Oct 20, 2011, at 12:52 PM, Tao Klerks wrote: > OK, I interpret this (besides the quite-reasonable "why should I care?" > vibe), combined with previous references to the PEG grammar(s) implicit in > MultiMarkdown and peg-markdown's implementations, as "a formal specification > already exists". True. "A" formal spec exists, but there needs to be agreement when "THE" formal spec exists. I personally believe that peg-markdown is a fantastic start, and could easily become the standard after being vetted by various developers and users around the troublesome edge cases that are out there. Others may disagree with me, but I see little reason to reinvent the wheel when there is a really good wheel sitting in front of us that might just need some tweaking. > That sounds fine - I'd love to use peg-(multi)markdown in my programs, but I > see two practical problems for that right now: > · A C library, while portable to any processor architecture, if not > portable to any development environment, and certainly not future-proof. I, > personally, would like to be able to rely on the exact same syntax not only > across the OSs that Fletcher mentions, but also in C# code (that can be > sandboxed safely - no P/Invoke calls to unsafe code) and also in browsers. > There are numerous other environments (Java, etc) where a similar "safe code" > requirement precludes the use of a C library (at least in browser and other > high-sandboxing environments). I suspect that no piece of code is going to be usable across all languages. If you want to write a Markdown parser in language X, you will likely have to rewrite it no matter how the standard is defined. But the PEG defines the syntax, and you can use that definition in whatever language you choose to write your parsing algorithm in. A library in ANSI C would seem to me to be as cross-compatible as we're going to get. It's not going to meet everyone's needs, but nothing will. We don't need a universal Markdown library. We need a definition of a standard. Said definition can be used in pascal or fortran for all I care. ;) That said, I would argue that an ANSI C program with no external requirements (peg-markdown itself requires glib2, but this can be removed as Daniel and I did with peg-multimarkdown) is the most cross-platform code available. If there is a standard, it should be able to be used on as many machine architectures as possible with as few requirements as possible. It seems that a portable chunk of C code fits this need. For example, pandoc, IIRC, is written in Haskell. Haskell may be a great language, but I've never used it and had trouble trying to get it all installed just so I could try things out. Perl is a pain in the neck for the average person to get running on Windows. I think the canonical definition should be available in something really basic, and C seems like the best approach to me. > · The PEG grammars(s) may be formal reproducible reusable > specifications, but my understanding is that they are not so meaningful > without a definition of what they map to. If my brief reading on this is > correct, a PEG grammar allows you to define behaviours to be executed upon > encountering certain source structures; those behaviours implement a > conversion to HTML, or latex, or whatever, but are implicit in the Program, > not the Specification/Grammar. Yes - you have to have a definition of how you output the HTML. peg-markdown also does this through example, not through a formal specification. I'm not an expert on formal grammars, but I wonder if there is a single formal specification that will define the syntax and the output in a single document? Or will there need to be a different approach? In either case, this is also where the test suite will come into play. > So if we take the current PEG-based implementations as a starting point, what > would it take to produce a specification that formally establishes not only > the source structures to be matched, but also the behaviour/conversions to be > implemented against them? Is this just a question of detailed documentation > and an open test-suite? I think so (but others might have a better solution) Any standard is going to require: 1) a definition of the Markdown syntax 2) a definition of the HTML output from said syntax 3) a test-suite that can be easily used for verifying various implementations peg-markdown provides all of these (using Gruber's perl test suite as a starting point - it is incomplete in regards to edge cases). I'm not saying it's perfect. Just that it's really good, and probably as good or better than almost anything out there, and it could be easily refined where necessary. > Another applicable question is: are PEG grammars easily usable in other > environments? A brief search suggests so (js: > http://stackoverflow.com/questions/79584/are-there-any-parsing-expression-grammar-peg-libr
Re: doesn't that make you wonder?
+++ Tao Klerks [Oct 20 11 12:52 ]: >OK, I interpret this (besides the quite-reasonable "why should I care?" >vibe), combined with previous references to the PEG grammar(s) implicit >in MultiMarkdown and peg-markdown's implementations, as "a formal >specification already exists". > > >That sounds fine - I'd love to use peg-(multi)markdown in my programs, >but I see two practical problems for that right now: > >· A C library, while portable to any processor architecture, if >not portable to any development environment, and certainly not >future-proof. I, personally, would like to be able to rely on the exact >same syntax not only across the OSs that Fletcher mentions, but also in >C# code (that can be sandboxed safely - no P/Invoke calls to unsafe >code) and also in browsers. There are numerous other environments >(Java, etc) where a similar "safe code" requirement precludes the use >of a C library (at least in browser and other high-sandboxing >environments). > >· The PEG grammars(s) may be formal reproducible reusable >specifications, but my understanding is that they are not so meaningful >without a definition of what they map to. If my brief reading on this >is correct, a PEG grammar allows you to define behaviours to be >executed upon encountering certain source structures; those behaviours >implement a conversion to HTML, or latex, or whatever, but are implicit >in the Program, not the Specification/Grammar > > >So if we take the current PEG-based implementations as a starting >point, what would it take to produce a specification that formally >establishes not only the source structures to be matched, but also the >behaviour/conversions to be implemented against them? Is this just a >question of detailed documentation and an open test-suite? > > >Another applicable question is: are PEG grammars easily usable in other >environments? A brief search suggests so (js: >[1]http://stackoverflow.com/questions/79584/are-there-any-parsing-expre >ssion-grammar-peg-libraries-for-javascript-or-php, C#: >[2]http://www.codeproject.com/KB/recipes/grammar_support_1.aspx not >GPL-compatible, sadly…); does anyone know how fesible it is to take the >existing PEG grammar(s) and reuse them in other languages? Translation of peg-markdown to Go: https://github.com/knieriem/markdown Java markdown parser based on peg-markdown: https://github.com/sirthias/pegdown And of course a PEG could provide a reference specification even for implementations that use other parsing methods. John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
+++ Fletcher T. Penney [Oct 20 11 13:22 ]: > > On Oct 20, 2011, at 12:52 PM, Tao Klerks wrote: > > > OK, I interpret this (besides the quite-reasonable "why should I care?" > > vibe), combined with previous references to the PEG grammar(s) implicit in > > MultiMarkdown and peg-markdown's implementations, as "a formal > > specification already exists". > > True. "A" formal spec exists, but there needs to be agreement when "THE" > formal spec exists. > > I personally believe that peg-markdown is a fantastic start, and could easily > become the standard after being vetted by various developers and users around > the troublesome edge cases that are out there. > > Others may disagree with me, but I see little reason to reinvent the wheel > when there is a really good wheel sitting in front of us that might just need > some tweaking. My more recent lpeg-based markdown implementation, lunamark, is better than peg-markdown in many respects. It passes more of the tests Michel Fortin made for PHP Markdown. It is also faster, and (I think) the code is more readable, since lua is a more expressive language than C. https://github.com/jgm/lunamark/blob/master/lunamark/reader/markdown.lua Sorry, I haven't kept track of the differences between the grammars of peg-markdown and lunamark. As for portability, well, nothing beats ANSI C, but lua comes close. The lua interpreter is small is itself implemented in ANSI C, as is the lpeg library. So lunamark could be made to run on anything that could run peg-markdown. > Yes - you have to have a definition of how you output the HTML. peg-markdown > also does this through example, not through a formal specification. I'm not > an expert on formal grammars, but I wonder if there is a single formal > specification that will define the syntax and the output in a single > document? Or will there need to be a different approach? In either case, > this is also where the test suite will come into play. It's better, in my opinion, to separate the parser and writer, as is done in peg-markdown. The parser produces an abstract syntax tree (AST), which the html and latex writers take as input. The writers are very simple; the difficulties lie with the parsing itself, and that's where a spec is really needed. There could be a separate spec for canonical HTML output. John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
RE: doesn't that make you wonder?
OK, so pardon my ignorance here: Am I right in assuming that there are are two people here who are responsible for at least 5 different but to-varying-degrees-compatible markdown systems/dialects? Fletcher T. Penney: - MultiMarkdown (original version/codebase) - peg-MultiMarkdown - MMD Composer (new PEG? why? the behaviours are obviously different, but how is the syntax tree different?) John MacFarlane - peg-markdown - pandoc - Lunamark +++ John MacFarlane [Thursday, October 20, 2011 1:46 PM] > >+++ Fletcher T. Penney [Oct 20 11 13:22 ]: >> Others may disagree with me, but I see little reason to reinvent the wheel when there is a really good wheel sitting in front of us that might just need some tweaking. > > My more recent lpeg-based markdown implementation, lunamark, is better than peg-markdown in many respects. It passes more of the tests Michel Fortin made for PHP Markdown. It is also faster, and (I think) the code is more readable, since lua is a more expressive language than C. But the main problem here, you both seem to agree, is to define a formal grammar that will define the correct AST for a base/common Markdown syntax, and could have a series of tests (be those the original John Gruber tests, or Michel Fortin's later ones) define "compliance" for a base set of features? John, you say the lunamark implementation is better, passes more of Michel Fortin's tests, and is "different" to peg-markdown to an unknown degree (because it presumably uses a different syntax to express the same grammar concepts?)... Is there any way for you and Fletcher to (without any significant amount of conversion work) understand what, if anything, would need to change in peg-markdown for it to represent an accurate common ground between both peg-MultiMarkdown and LunaMark? Fletcher, there's one thing I'm not completely clear on: besides the syntax extensions that you made, is peg-MultiMarkdown still basically doing the same as peg-markdown for 99% of cases where peg-MultiMarkdown's features/extensions are not explicitly/purposefully used by an end-user? Or have you made changes to the "base" workings to accommodate your additional syntax requirements? Sorry if I'm being overly familiar here - I just felt, for a few moments, like I was seeing some light at the end of the tunnel. Thanks, Tao -Original Message- From: markdown-discuss-boun...@six.pairlist.net [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of John MacFarlane Sent: Thursday, October 20, 2011 1:46 PM To: Discussion related to Markdown. Subject: Re: doesn't that make you wonder? +++ Fletcher T. Penney [Oct 20 11 13:22 ]: > > On Oct 20, 2011, at 12:52 PM, Tao Klerks wrote: > > > OK, I interpret this (besides the quite-reasonable "why should I care?" vibe), combined with previous references to the PEG grammar(s) implicit in MultiMarkdown and peg-markdown's implementations, as "a formal specification already exists". > > True. "A" formal spec exists, but there needs to be agreement when "THE" formal spec exists. > > I personally believe that peg-markdown is a fantastic start, and could easily become the standard after being vetted by various developers and users around the troublesome edge cases that are out there. > > Others may disagree with me, but I see little reason to reinvent the wheel when there is a really good wheel sitting in front of us that might just need some tweaking. My more recent lpeg-based markdown implementation, lunamark, is better than peg-markdown in many respects. It passes more of the tests Michel Fortin made for PHP Markdown. It is also faster, and (I think) the code is more readable, since lua is a more expressive language than C. https://github.com/jgm/lunamark/blob/master/lunamark/reader/markdown.lua Sorry, I haven't kept track of the differences between the grammars of peg-markdown and lunamark. As for portability, well, nothing beats ANSI C, but lua comes close. The lua interpreter is small is itself implemented in ANSI C, as is the lpeg library. So lunamark could be made to run on anything that could run peg-markdown. > Yes - you have to have a definition of how you output the HTML. peg-markdown also does this through example, not through a formal specification. I'm not an expert on formal grammars, but I wonder if there is a single formal specification that will define the syntax and the output in a single document? Or will there need to be a different approach? In either case, this is also where the test suite will come into play. It's better, in my opinion, to separate the parser and writer, as is done in peg-markdown. The parser produces an abstract syntax tree (AST), which the html and latex writers take as input. The writers are very simple; the difficulties lie with the parsing itself, and
Re: doesn't that make you wonder?
On Oct 20, 2011, at 2:13 PM, Tao Klerks wrote: > OK, so pardon my ignorance here: Am I right in assuming that there are are > two people here who are responsible for at least 5 different but > to-varying-degrees-compatible markdown systems/dialects? > > Fletcher T. Penney: > - MultiMarkdown (original version/codebase) > - peg-MultiMarkdown > - MMD Composer (new PEG? why? the behaviours are obviously different, but > how is the syntax tree different?) peg-mmd (MMD 3) replaces the old perl version 2. v 2 still exists on github, but I am no longer actively developing it. Trying to bring it into compliance with MMD 3 was going to take too much work to be justified. Anyone else is welcome to continue working on it, however. Composer uses the same syntax as MMD 3, and uses MMD 3 itself to handle previews/exports. The PEG has to be modified because we are highlighting, not parsing. PEGs are not drop-in magic bundles that do everything for you. They define how to parse the input text. It's up to the programmer to do something useful with that parsing. But think of Composer as an implementation of MMD 3, not as something distinct in this sense. > John MacFarlane > - peg-markdown > - pandoc > - Lunamark > But the main problem here, you both seem to agree, is to define a formal > grammar that will define the correct AST for a base/common Markdown syntax, > and could have a series of tests (be those the original John Gruber tests, > or Michel Fortin's later ones) define "compliance" for a base set of > features? Yes. I think it's useful to have a "reference" implementation that demonstrates that formal grammar. But the standard should be the grammar itself, not a specific implementation (which was one of the problems with Gruber's "the implementation is the reference" approach). > John, you say the lunamark implementation is better, passes more of Michel > Fortin's tests, and is "different" to peg-markdown to an unknown degree > (because it presumably uses a different syntax to express the same grammar > concepts?)... Is there any way for you and Fletcher to (without any > significant amount of conversion work) understand what, if anything, would > need to change in peg-markdown for it to represent an accurate common ground > between both peg-MultiMarkdown and LunaMark? If John brought peg-markdown into compliance with lunamark, then by extension peg-multimarkdown would be compliant when I pulled his changes. > Fletcher, there's one thing I'm not completely clear on: besides the syntax > extensions that you made, is peg-MultiMarkdown still basically doing the > same as peg-markdown for 99% of cases where peg-MultiMarkdown's > features/extensions are not explicitly/purposefully used by an end-user? Or > have you made changes to the "base" workings to accommodate your additional > syntax requirements? If you run peg-multimarkdown with the "compliant" flag, it *should* be 100% identical in output to peg-markdown. Composer has a preference that does just that. Any differences between the two are unintentional, and problems could be readily fixed when identified. > Sorry if I'm being overly familiar here - I just felt, for a few moments, > like I was seeing some light at the end of the tunnel. That's why I brought up some of the points the way I did today. I feel like MacFarlane has a done a great job formalizing much of the Markdown syntax. That's not to say that his interpretation is entirely correct, or that others have not done an equally good job. When I decided to rewrite MMD last fall, his implementation seemed to be the most flexible, cross-platform, and easily understood approach. So I went with it, and now it's the one I'm most familiar with. That's why I feel like it is 90% of the way towards being a useable standard. Other developers can test out various edge cases and bring them up for discussion. Appropriate changes can be made as needed to the underlying formal grammar. A test suite can then be developed. I believe that the issue of standardizing the syntax extensions will be a more challenging problem to tackle. But this would be a huge step, and probably generate momentum that would carry over. 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: doesn't that make you wonder?
OK, so just one follow-up, for my understanding if nothing else: If a PEG is a grammar, and you need to "hook in" to it to get it to do useful things like converting markdown to html, then why would you need to change that PEG (definition/grammar) to USE it to do some other thing, like produce some way to highlight some text in an OSX app? Wouldn't you just change the "hooks"? Did you really have to change the PEG, or did you just change the functions/events/[insert C-appropriate or PEG-appropriate keywords here. "Actions" maybe?] that hook into it? Is the problem that the two are interspersed in the current implementation/file? Sorry, I've only very briefly looked at the "markdown_parser.leg" files in peg-markdown and peg-multimarkdown, haven't yet had the chance to dive in and actually try to understand them - I was assuming the PEG itself is entirely defined between those strange looking "%}" and "%%" delimiters in the file. Sorry I'm harping on about this, but I'm trying to understand whether/how a completely new program, in a completely different environment, could correctly parse the input (let's forget about generating the output - obviously that portion will depend on the language/environment/framework) WITHOUT writing a new PEG or equivalent and hoping it's defining the same AST. I'm hoping (wishfully maybe) that it can simply be copy/pasted, and then another framework build around it for the "Actions". From: markdown-discuss-boun...@six.pairlist.net [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Fletcher T. Penney Sent: Thursday, October 20, 2011 2:35 PM To: Discussion related to Markdown. Subject: Re: doesn't that make you wonder? Composer uses the same syntax as MMD 3, and uses MMD 3 itself to handle previews/exports. The PEG has to be modified because we are highlighting, not parsing. PEGs are not drop-in magic bundles that do everything for you. They define how to parse the input text. It's up to the programmer to do something useful with that parsing. But think of Composer as an implementation of MMD 3, not as something distinct in this sense. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
+++ Fletcher T. Penney [Oct 20 11 13:22 ]: > For example, pandoc, IIRC, is written in Haskell. Haskell may be a great > language, but I've never used it and had trouble trying to get it all > installed just so I could try things out. You shouldn't need to install a Haskell compiler (though this has gotten pretty easy with the Haskell Platform). Pandoc has binary installers for Windows and OSX (intel): http://code.google.com/p/pandoc/downloads/list If you use linux, your package manager probably has it. (It's in debian/fedora/arch/gentoo/freebsd.) John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
Perhaps an (admittedly trivial) example will help:
peg-mmd:
Block = BlankLine*
( BlockQuote
| Verbatim
| &{ !extension(EXT_COMPATIBILITY) } DefinitionList
| &{ !extension(EXT_COMPATIBILITY) } Glossary
| Note
| Reference
| HorizontalRule
| HeadingSection
| OrderedList
| BulletList
| HtmlBlock
| StyleBlock
| &{ !extension(EXT_COMPATIBILITY) } Table
| &{ !extension(EXT_COMPATIBILITY) } ImageBlock
| !(Sp? HtmlBlockOpenDiv) Para
| Plain )
Composer:
Block = BlankLine*
( BlockQuote
| Verbatim
| &{ EXT(EXT_MMD) } DefinitionList
| &{ EXT(EXT_MMD) } Glossary
| Note
| Reference
| HorizontalRule
| HeadingSection
| OrderedList
| BulletList
| HtmlBlock
| StyleBlock
| &{ EXT(EXT_MMD) } Table
| &{ EXT(EXT_MMD) } FutureTable
| Para
| Plain )
The PEG is basically the same in defining what to match, but the C commands
(inside the {}) are different based on the requirements of the separate
programs.
It sounds like you want a single document that can be pasted into any program
in any language and work. I suspect such a think doesn't exist.
A PEG in this style is close, in that it defines an algorithm for parsing the
input text that can be reused in a variety of contexts, but it will require
customization to suit the particular needs of the program.
F-
On Oct 20, 2011, at 3:16 PM, Tao Klerks wrote:
> OK, so just one follow-up, for my understanding if nothing else:
>
> If a PEG is a grammar, and you need to "hook in" to it to get it to do useful
> things like converting markdown to html, then why would you need to change
> that PEG (definition/grammar) to USE it to do some other thing, like produce
> some way to highlight some text in an OSX app? Wouldn't you just change the
> "hooks"? Did you really have to change the PEG, or did you just change the
> functions/events/[insert C-appropriate or PEG-appropriate keywords here…
> "Actions" maybe?] that hook into it? Is the problem that the two are
> interspersed in the current implementation/file? Sorry, I've only very
> briefly looked at the "markdown_parser.leg" files in peg-markdown and
> peg-multimarkdown, haven't yet had the chance to dive in and actually try to
> understand them - I was assuming the PEG itself is entirely defined between
> those strange looking "%}" and "%%" delimiters in the file.
>
> Sorry I'm harping on about this, but I'm trying to understand whether/how a
> completely new program, in a completely different environment, could
> correctly parse the input (let's forget about generating the output -
> obviously that portion will depend on the language/environment/framework)
> WITHOUT writing a new PEG or equivalent and hoping it's defining the same
> AST. I'm hoping (wishfully maybe) that it can simply be copy/pasted, and then
> another framework build around it for the "Actions".
>
--
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: doesn't that make you wonder?
OK, I appreciate the example might be dumbed-down here, but again there is
no reason the two programs couldn't use the exact same function and constant
names, is there? You could easily define a canonical peg (leg) file and have
the constant/function names be part of its "implementation interface".
The only functional difference I see between these two samples is the "!(Sp?
HtmlBlockOpenDiv)" part in MMD that does not feature in Composer. (and I'm
actually curious - what does that difference mean? maybe a subject better
explored offline, when I've done my homework and stand a chance of
recognizing some syntax :))
All that said, I have looked briefly into the PEG frameworks listed at
http://bford.info/packrat/ (looks like the definitive list!), and it looks
like every one has its own syntax, or at least subtleties of implementation.
To implement something in Javascript (and maybe also C#), it looks like
you'd need to start by converting the LEG definition into an
OMeta-compatible format. I guess it will never be trivial.
From: markdown-discuss-boun...@six.pairlist.net
[mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Fletcher T.
Penney
Sent: Thursday, October 20, 2011 5:00 PM
To: Discussion related to Markdown.
Subject: Re: doesn't that make you wonder?
Perhaps an (admittedly trivial) example will help:
peg-mmd:
Block = BlankLine*
( BlockQuote
| Verbatim
| &{ !extension(EXT_COMPATIBILITY) } DefinitionList
| &{ !extension(EXT_COMPATIBILITY) } Glossary
| Note
| Reference
| HorizontalRule
| HeadingSection
| OrderedList
| BulletList
| HtmlBlock
| StyleBlock
| &{ !extension(EXT_COMPATIBILITY) } Table
| &{ !extension(EXT_COMPATIBILITY) } ImageBlock
| !(Sp? HtmlBlockOpenDiv) Para
| Plain )
Composer:
Block = BlankLine*
( BlockQuote
| Verbatim
| &{ EXT(EXT_MMD) } DefinitionList
| &{ EXT(EXT_MMD) } Glossary
| Note
| Reference
| HorizontalRule
| HeadingSection
| OrderedList
| BulletList
| HtmlBlock
| StyleBlock
| &{ EXT(EXT_MMD) } Table
| &{ EXT(EXT_MMD) } FutureTable
| Para
| Plain )
The PEG is basically the same in defining what to match, but the C commands
(inside the {}) are different based on the requirements of the separate
programs.
It sounds like you want a single document that can be pasted into any
program in any language and work. I suspect such a think doesn't exist.
A PEG in this style is close, in that it defines an algorithm for parsing
the input text that can be reused in a variety of contexts, but it will
require customization to suit the particular needs of the program.
F-
On Oct 20, 2011, at 3:16 PM, Tao Klerks wrote:
OK, so just one follow-up, for my understanding if nothing else:
If a PEG is a grammar, and you need to "hook in" to it to get it to do
useful things like converting markdown to html, then why would you need to
change that PEG (definition/grammar) to USE it to do some other thing, like
produce some way to highlight some text in an OSX app? Wouldn't you just
change the "hooks"? Did you really have to change the PEG, or did you just
change the functions/events/[insert C-appropriate or PEG-appropriate
keywords here. "Actions" maybe?] that hook into it? Is the problem that the
two are interspersed in the current implementation/file? Sorry, I've only
very briefly looked at the "markdown_parser.leg" files in peg-markdown and
peg-multimarkdown, haven't yet had the chance to dive in and actually try to
understand them - I was assuming the PEG itself is entirely defined between
those strange looking "%}" and "%%" delimiters in the file.
Sorry I'm harping on about this, but I'm trying to understand whether/how a
completely new program, in a completely different environment, could
correctly parse the input (let's forget about generating the output -
obviously that portion will depend on the language/environment/framework)
WITHOUT writing a new PEG or equivalent and hoping it's defining the same
AST. I'm
