Re: Leading/trailing whitespace in inline
that is why your patch to _DoCodeSpans is wrong. Now, it might be possible to salvage your proposal by introducing an exception, that trimming spaces from code spans only applies when more than a single backtick is used as the delimiter. But that would make the rules more complicated, and it only allows you to use your workaround, which is pretty cruddy anyway – you’re writing multiple code spans where there really is only one piece of code. Write it with HTML tags. That’s really your answer. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: Original Markdown.pl v1.0.1 Script (Anno 2004) Unzipped and Archived for Easy Browsing on Github
Hi Gerald, * Gerald Bauer <gerald.ba...@gmail.com> [2017-03-20 14:48]: > Anyone knows if the original Markdown.pl [1] script by John Gruber > has a home on GitHub (or similar service) for easy browsing? some time ago I set up a repo which has each Markdown.pl release as a commit on master: https://github.com/ap/Markdown Or rather, every release I could still find. The release tarballs and zips are all committed in the `sources` branch, together with a script to generate the `master` branch history from them, plus a README to explain the whole conceit: https://github.com/ap/Markdown/tree/sources I have been intending to ping John about this, as well as to put out a public call for anyone who happens to still have other releases, but that hasn’t happened yet. Nevertheless, what’s there is at least a start. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: does fireball markdown support anchor links?
* Michel Fortin michel.for...@michelf.ca [2015-07-09 16:20]: I'm not providing this function out of the box for a few reasons: 1. any specific algorithm to generate the id to is going to make some people complain about non-compatibility with another implementation, and 2. it's quite hard to come with something that'll work well with non-english text. There’s also another important reason: Markdown is used for document fragments that get combined into a single web page, much more often than it is used for standalone, single full page documents. E.g. the front page of a weblog with excerpts from multiple articles; comments in a thread on Reddit, or on GitHub; etc. But anchors must be unique. The Markdown processor alone does not have enough information and state to generate sufficiently unique anchors in such an environment. So, if automatically generated anchors are desired, their derivation *must* be performed by code from the environment which has sufficient information to be able to do that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: Opinions on in-band variation signaling
* Sean Leonard dev+i...@seantek.com [2014-11-12 00:50]: At least one commentator (Larry Masinter) specifically requested that the variant identifier be included in-band in the Markdown content, rather than as part of the metadata. I disagree with in-band signaling (as has been registered earlier on this list). Both have value. Ruby’s postulate: The accuracy of metadata is inversely proportional to the square of the distance between the data and the metadata. That is to say, a value signalled in-band will be correct much more often than one signalled via MIME/HTTP headers. Also, in-band vs out-of-band simply address different scenarios. An in-band signal travels with the data automatically, without any special measures taken, whereas out-of-band metadata has a fair chance of getting lost somewhere in transit. How is a user agent supposed to store the variant parameter from the content-type after downloading a Markdown file to disk? But if you want to make decisions about the data during transit, having to parse the payload to find the signal is prohibitively expensive. An out-of-band signal is cheap, and is visible to a lot of infrastructure that would never implement such specialised parsing of payloads such as Markdown. (I mean, that is the exact same reason for having a MIME type separate from text/plain in the first place.) It’s nonsensical to portray this as a binary choice between two options. Those are two separate choices and discussions. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: Markdown within block-level elements
* ja...@gmx.at ja...@gmx.at [2014-09-19 13:15]: For easy copy pasting, backwards compatibility etc (as others just pointed out), markdown=0 should imo be default for any HTML element. As in PHP markdown, let markdown=1 interpret inline stuff inside that element. Then let markdown=2 make the child element inherit markdown=1 and so on, eg.: div markdown=2 Inline markdown *here*. .divfirst level child: markdown is *on* ..divsecond level child: markdown is emoff/em again. ../div ./div /div So the concept is, that the number given will be counted down before inheriting it. I think there is a Markdown converter that supports something like that already. I saw someone mention it on this list a while ago, anyway. It seems like a smart solution. Markdown=all (or similar) would inherit through all levels. To escape inheritance, put markdown=0 there again. That one I hadn’t seen before. Makes a lot of sense too. To simplify things, one could also leave out the counting down thing and only have three States: off, on*, all levels*. That’s certainly how you want to introduce it in the syntax description. I’m not sure if it would cover enough ground without supporting counted levels. Still, you don’t lose any use cases by not supporting them, you just make some documents more noisy. So the best approach is probably to just try the simple form and see if you miss counted level support. If you want to have an all markdown document, wrap it into an element with markdown=all (or all-block). However, there might be situations where you don't want to output any extra element; I'm not sure whether a pseudo-element like markdown (or !-- markdown -- ?) would be a good solution to this. In the spirit of “the simple form is probably enough” I would just punt on that. Great, now you just need to convince some sufficient number of Markdown converter authors/maintainers to support this extension. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: Markdown within block-level elements
* Alan Hogan cont...@alanhogan.com [2014-09-18 03:10]: I do not understand why the rule existed in the first place. Which implies that it must not make sense? The rule allows you to retroactively introduce Markdown to any system that was designed to handle HTML, without breaking any existing content. And if the Markdown processor needs to be jammed at multiple different layers, you can do that, because the HTML rendering of a Markdown source is always wrapped in block-level elements, so you can pass the output of a Markdown converter back through it (or through another converter, if you happen to be stacking plugins in a CMS, say) without destroying it. Without the rule, you would have to choose between Markdown and HTML. The rule makes Markdown embrace-and-extend. Break things. Bump the major version. Be part of an ecosystem that actually works. Markdown is Gruber’s and not anyone else’s. There is no “ecosystem” about that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: It's a Markdown processor, right?
* Andrei Fangli andrei_fan...@hotmail.com [2014-09-07 10:45]: When I hear Markdown processor I think of a specialized word/text processor That is not what it generally mean in RFCs. The XML specs speak of an XML processor, the Atom RFCs speak of an Atom processor, etc. So I think the terminology here is correct for an RFC. (To me what you refer to is a “Markdown word processor”, esp considering that a word processor is called a *word* processor rather than, say, an RTF processor or a DOC processor.) I’ll also defend the term on grounds of its meaning later, but let me first address the proposed alternatives: For me, Markdown implementation sounds a bit odd. Markdown is not standardized nor is its specification clear enough Agree. I’d simply name the specification (or flavour) and append “Translator” at the end (e.g.: Github flavoured Markdown Translator, Common Markdown Translator etc.). That is specific to a use case. E.g. multiple MacOS X QuickLook plugins for Markdown preview exist; these are not translators, all they can do is display the document (or a portion of it). Internally they may use a translator, as most probably do, but they may just as well be written on top of a Markdown parser that merely creates an AST rather than any kind of output; either way it’s an implementation detail. * Andrei Fangli andrei_fan...@hotmail.com [2014-09-07 17:00]: Parsing is all about syntactic analysis, a parser may well just return true and false depending on whether the input is syntactically correct or not. Yes, agree: “parser” is not the right term. It’s also not the right term because a translator need not necessarily parse the document. Markdown.pl doesn’t. So actually, “Markdown parser” in fact excludes the canonical Markdown… processor. I’m not very comfortable about calling them libraries if they are actually executables or scripts. Agree here also. So… Ultimately, to come back to the beginning of my mail, what you want to express is “a piece of software that will take Markdown and do something with it in some Markdown-rules-informed way”. You want to cover any kind of doing something, be it translating to another format or displaying the document or extracting something from it (e.g. indexing or counting words or whatever) or anything else. You want to cover any form in which software comes, be that a library, an executable, or just an incidental part of some larger library or application. And you want to allow for it implementing any fraction of the total Markdown rules (e.g. a Markdown word counter could ignore most inline formatting as punctuation without it making a difference in the result), and in whichever form it chooses (it could use parsing, or not). I would argue that the only sufficiently generic term that will apply to software in all of these cases is, in fact, “processor”. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: It's a Markdown processor, right?
* Waylan Limberg waylan.limb...@icloud.com [2014-09-08 03:55]: How about some of the verbs used by libraries as a method on a class instance: render or convert. Of course we want the nouns: renderer or converter. They are very similar to translator, but unlike translator are actually used by the existing implementations. That would exclude parsers, indexers, etc. whose output is not another form of the document. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown validity Re: Agreeing on Historical Markdown
* Sean Leonard dev+i...@seantek.com [2014-07-12 16:35]: However, if you have Markdown in the HTML content with markdown=1 as with PHP Markdown Extra, it is necessary to parse the HTML with something other than a straight HTML parser since the straight HTML parser will misinterpret the Markdown (e.g., will be a validation error). That parser is Markdown itself. You can already put Markdown inside HTML tags, it’s just that normally Markdown will only parse the content of inline tags like EM and SPAN, not block tags like P or DIV. This was an explicit design choice. The markdown=1 attribute does nothing more than turn off this distinction temporarily. (The block tag rule allows you to write portions of your document as plain old HTML when Markdown is insufficient, and also allows you to pass stuff through Markdown several times (e.g. fragments in a CMS getting passed through Markdown at various stages of page assembly) without screwing up the document. I consider it the smartest choice in the design of Markdown: the reason it has been adopted where other syntaxes have remained confined to niches. It means almost any HTML fragment is also a Markdown fragment, so it’s easy to add Markdown to any publishing workflow that involves HTML somewhere even if it wasn’t designed for that at all, and the content can then be ported piecemeal instead of boil-the-ocean. Classic embrace-and-extend.) Therefore: Markdown has no concept of markdown validity. Correct. Markdown may have a concept of HTML validity. Not really. Individual processors may, but Markdown itself has nothing to say about that. The original implementation of course is implemented as a text substitution system, which means if you give it Markdown that contains invalid HTML then you’ll simply get HTML that’s invalid in the same way, to then be interpreted by the browser however the browser may. My guess is that the majority of implementations behave equivalently to this, though depending on their design they could differ completely. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown internal metadata Re: Markdown validity
* Alan Hogan cont...@alanhogan.com [2014-07-10 23:00]: You are entirely correct that there is a strong chance that this API call would actually send an updated copy of a JSON object including fields such as “title”, “date”, “url”, and “body”, the last of which may implicitly or explicitly be Markdown data. (And the MIME type on that call would be application/json or whatever.) But perhaps the most RESTful way to do this would be to send a plain Markdown file (as text/markdown). Perhaps, yes, but not actually. As far as ReST is concerned, either approach is equally valid. However, it is nicer if you can use a wide-spread MIME type that is more specific than something ultra-generic like application/json, since these generic MIME types tell you essentially nothing about the application- level meaning of the data, which weakens the utility of intermediaries. (I.e. a reverse proxy in front of your app might try to do clever stuff based on the MIME type of a request; if your data is overly generically labelled then the proxy must parse the response body to figure out what type of data it is dealing with. Conversely for the same reason you also don’t want to invent ultra-specific one-off MIME types, because existing infrastructure will have no idea what type of thing that might be.) But it is totally feasible for a few standard rules to be applied by the server to extract metadata from the content of a Markdown document. That is in fact exactly what my own hack for serving a directory full’a Markdown files as a static site does. Furthermore, * Sean Leonard dev+i...@seantek.com [2014-07-13 02:30]: I tried to do some head stuff, as in: http://johnmacfarlane.net/babelmark2/?text=%3Chead%3E%3Ctitle%3EHello+World%3C%2Ftitle%3E%3Cmeta+name%3D%22author%22+content%3D%22Alice%22%3E%3C%2Fhead%3E%0A%0AI+am+some+text.%0A%3Cdiv%3Eand+i+am+inside+*myself*%3C%2Fdiv%3E%0A%0AThe+end. And not surprisingly, the results are all over the place. Clearly this is not an effective way to communicate HTML metadata, since Markdown is designed to process HTML block-level content. … I use a hacked Markdown processor that treats head-level elements just like block-level elements (I find it a missed opportunity that at least this much is not part of standard Markdown), then I run a HTML5 parser over the output to normalise it and finally, I use an XSL transform against the DOM from that to pull any remaining head elements up into the head, before re-serialising the whole shebang. (The H1-as-title extraction is only a fallback. So I can give documents an explicit title different from their first heading, or even provide a title when there are no headings present.) (I have designs for releasing this thing someday but its current form is cobbled together too hackily to work for anyone else.) Which leads me to: * Waylan Limberg waylan.limb...@icloud.com [2014-07-13 03:30]: I should also point out that a number of projects will use the first h1 Header in the document as the title. And if the file is stored on the file system, the creation and modification date may be pulled from the file system. a) Yup, exactly. * Waylan Limberg waylan.limb...@icloud.com [2014-07-10 17:55]: Why do we need a Mime Type? b) I find the need for a MIME type trivially evident because I already have directories full of files with nothing but Markdown in them. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Carl Jacobsen li...@carlrj.com [2014-07-10 12:50]: So, you might have: content-type=text/markdown flavor=tables+titleblock processor=floobity-1.2.3 That’s very nice, except it will never happen. • No user is going to annotate their files in such a way that this MIME type would ever show up in the wild in such specificity, unless they use special software which automatically records the relevant metadata (rather than just a text editor + file system workflow). • No implementor is going to write a Markdown processor that is actually capable of dealing with this MIME type. (Except of course the author of floobity 1.2.3 itself, in this example, of course – which is not for any attempt at making it work in a generic way.) • If the flavours refer to existing syntax extensions and modifications, those are all only vaguely specified, and the implementations that offer them are not likely to be changed to follow a more rigorous spec of the respective syntax extension any time soon. So in practice these flavour specs are no more well-defined than saying the document is (some kind of) Markdown. • Documents are generally written for a specific processor, not for some particular combination of syntax extensions in the abstract. There are a number of processors which implement half a dozen separate syntax extensions. Documents written for these processors notionally employ all of these syntax extensions. Will documents in e.g. GitHub-Flavored Markdown always have to list the entire enchilada in their MIME type (instead of just saying “GFM”)? Or do you force whatever part of the infrastructure picks the MIME type to parse the document (and contain knowledge of all possible syntax extensions) to figure out which of them are actually used? • I won’t make a separate bullet point for the endless effort of keeping track of all the possible syntax extensions, which is going to be a cat herder job, because that should be an obvious problem. But what if someone wants to implement a new syntax extension – what process do they have to go through before they can assign a truthful MIME type to their documents? Metadata is hard. Let’s go shopping. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Fletcher T. Penney fletc...@fletcherpenney.net [2014-07-10 18:30]: I suppose it's debatable as to how non-local that effect is considered, I do consider that local. “Local-enough” at least. Tellingly though it’s also the most common single reason for “how do I” user inquiries on this list. A less debatable example is fenced code blocks Yes, true. The annoying thing is, while I was against them when the proposal was brought up for Markdown in general, after spending some time using them (by way of GitHub), I do find them convenient as a user. So now I have a dilemma. — • — Still though – because fenced code blocks are an extension, they don’t much change the principle of what I said: if you use a fenced code block, then try to render the document using some other processor which doesn’t support them, you get a garbled code block and then the rest of the document after that looks fine. Conversely a documents written for processors that do not support fenced code blocks are rather unlikely to contain something that looks as if it were – which would then lead to large-scale botch if you tried to render them using a processor that supports fenced code blocks. (I feel this is especially so for backtick fences. Tilda fences seem to have some remote likelihood of being used as an innocuous part of a non-fenced-code-block document.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
* Sean Leonard dev+i...@seantek.com [2014-07-09 22:10]: Markdown has no way to communicate the character set in the document (other than the Unicode Byte Order Marks, which is a generalized property about text streams, not specific to Markdown)--and it would be counterproductive to invent one. So that is a perfect example of relevant metadata. And the second one, is how to turn it into something else that the author wants. If it's not communicated, it's going to be implied. Implied means guessing and likely guessing wrong. Yet guessing wrong is largely without consequence. There are really no syntax features that affect the document’s rendering non-locally. If part of a document is written with unsupported syntax, only that part will render incorrectly, but the other parts will come out fine. And there are no large overlapping surfaces among the syntaxes of the various extensions (esp. those for very different document features), which makes unsupported syntax unlikely to appear to have been intended to be rendered as some completely dissimilar feature. So you will get a document that differs from the author’s intent in some way. But it will be clear *where* the differences are and you will still get all of the data in *some* form, quite possibly fully intelligible if not pretty. And because of the primary goal of Markdown to be human-readable in its source form, there is always an easy and cheap last resort: view source. Bottom line, misrendering a document due to wrong choice of flavour is annoying but inconsequential, due to the very nature of Markdown. Therefore the flavour parameter ought to be considered nothing more than loosely informative, and the processor should just render the document to the best of its ability regardless of the flavour specified. It MAY use the parameter value to adapt to the document, in RFC 2119 lingo, but ought not be bound by it. Furthermore, an absent flavour parameter ought to mean that the flavour is unspecified, not that it is any particular default flavour; i.e. the choice of flavour in that case ought to be up to the processor. Lastly, the spec should mention (as informal guidance to implementors) that applications containing Markdown processors which have any chance of being exposed to source documents of unknown flavour should, if at all possible, provide a means for the user to view the source Markdown document in unformatted form. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: attribute blocks for definition lists
* Andy Lee ag...@mac.com [2013-07-01 18:55]: Out of curiosity, do I understand correctly that term : definition is already in common usage when people write plain text? I was not aware of that, so if so, I may start adopting it in my own emails etc. I’ve never seen it in email. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Styling Markdown approaches
* Sherwood Botsford sgbotsf...@gmail.com [2013-04-20 16:20]:
It's actually worse than that, because for me MMD is actually a module
in Template Toolkit. So my information is MD markup wrapped in
a preface and epilog of template toolkit.
[% FILTER replace('[^/][^]*\K', ' markdown=1') # Perl 5.10+ required for
\K %]
div
*Hooray!!*
/div
[% END %]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Styling Markdown approaches
* Sherwood Botsford sgbotsf...@gmail.com [2013-04-18 17:20]: (I wish that this was a toggle that could be set in a .mmdrc file. There are a lot of things that I wish I could set in an .mmdrc file.) That would be bad for Markdown. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: ToDo List Notation
* Clint Laskowski clint.laskow...@gmail.com [2011-12-11 16:15]: Thoughts? You are looking for orgmode. Markdown is the wrong tool. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: fuck yeah markdown
* bowerb...@aol.com bowerb...@aol.com [2011-10-15 22:00]: brett has accomplished more in the last three months than this listserve accomplished in the last three years. Well, we can agree he has achieved more in three months than you have in a decade of talking. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: doesn't that make you wonder?
* bowerb...@aol.com 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: An Observation
* Michel Fortin michel.for...@michelf.com [2011-05-14 23:40]: Le 2011-05-14 à 15:55, Aristotle Pagaltzis a écrit : An anatomy of a loss of interest: 2004 279 2005 153 2006 78 2007 25 (21 in the first half of the year) 20086 (2 in Feb; 4 in a row in mid-March) 20094 (in row in late Feb) 20100 20110 It’s not uncommon. Most of my own projects look like this… I just wish we’d get one last release out of him that takes the beta label off the last version and fixes the couple of small things Gruber himself already agreed years ago should be changed in certain ways. (Eg. not triggering emphasis on word-internal underscores.) You should add a new column for the total number of posts. 2004 279 / 938 2005 153 / 856 200678 / 542 200725 / 479 (21 in the first half of the year) 2008 6 / 508 (2 in Feb; 4 in a row in mid-March) 2009 4 / 235 (in row in late Feb) 2010 0 / 203 2011 0 / 141 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: An Observation
* Fletcher T. Penney fletc...@fletcherpenney.net [2011-05-14 16:50]: I was looking at the original Markdown syntax specification, and became curious as to the last time Gruber posted anything to this discusion list. According to some searches of the archives using some Google tricks, the last post I could find from him was in 2009. Just thought that was interesting. An anatomy of a loss of interest: 2004 279 2005 153 2006 78 2007 25 (21 in the first half of the year) 20086 (2 in Feb; 4 in a row in mid-March) 20094 (in row in late Feb) 20100 20110 It’s not uncommon. Most of my own projects look like this… I just wish we’d get one last release out of him that takes the beta label off the last version and fixes the couple of small things Gruber himself already agreed years ago should be changed in certain ways. (Eg. not triggering emphasis on word-internal underscores.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: What does Markdown do with HTML comments? Recommendation on Markdown file extension?
* Waylan Limberg way...@gmail.com [2011-05-05 03:25]: However, most projects I'm aware of use '.md' or '.markdown'. `.mkd` and `.mkdn` are also popular. I’ve seen `.mdwn` also, and I think even `.mdn` though I’m not sure about that one. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: ol start with a specific number?
* Waylan Limberg way...@gmail.com [2011-04-07 04:15]: I'm not opposed to adding this, but I noticed that no other implementation (of those on Babelmark) implements this by default (not counting Pandoc's extended mode). I haven't checked if other implementations offer this as an option. John’s reason was that the `start` attribute was deprecated in HTML 4 Strict. He has since said at least once that this reasoning was flawed and the decision a mistake. My question is: should this be an option to turn on and off, and if so, should it be on or off by default? Bitter as it may be I think you would need to leave it off by default. Interoperability is important. Given that statement, it would seem that on by default and without an option to turn if off would be fine. I wish John would make another release to straighten out these handful of known tiny niggles… since his is the implementation that everyone else’s will follow. But what is the reality in the real world? If I did that, would a bunch of documents suddenly start rendering incorrectly - or at least different that expected? I guess the real question is: has everyone been ignoring that piece of advice in the docs and if so, is this something we should care about as implementors? It’s not that simple. Consider what happens if some user writes a document while previewing it with your implementation, which advertises itself as Markdown, then pastes it into the textarea in some web app, which also advertises Markdown support. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Any way to get syntax-highlighted code blocks with Text::MultiMarkdown?
* Dr. Drang drdr...@gmail.com [2010-12-06 17:10]: I just added syntax highlighting to my blog by wedging a call to Pygments into my fork of PHP Markdown Extra (yet another abuse of Michel's code). You could do a similar thing with MultiMarkdown by changing the _DoCodeBlocks function. Markdown spits out HTML. Any highlighter that can fish `pre` and `code` out of HTML and highlight it will work on the Markdown’s output. There is no need to wedge any of this into Markdown itself. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: markdown do not support Strikethrough ?
* John MacFarlane j...@berkeley.edu [2010-07-23 17:50]: But using HTML isn't a great solution for pandoc, which supports many output formats. IMO separating Markdown from HTML is the wrong approach. Likewise everyone who filters out `em` but allows asterisks for emphasis is doing it wrong. Markdown is an alternative syntax for HTML. The right thing to do with a Markdown document is convert it to regular HTML, *then* optionally apply a tag white list, *then* optionally convert this HTML (subset) document to other formats. If there are HTML tags you cannot (easily) support in your target formats, just omit them from your supported subset of HTML. That way you support real Markdown, not a crippled Markdown-lookalike syntax. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: using markdown in a forum?
* Louis-David Mitterrand vindex+lists-markdown-disc...@apartia.org [2010-05-05 16:05]: What would be a reasonable defaults whitelist for html tags in a forum context? All the tags Markdown has syntax for: em strong a img code br p ul ol li blockquote pre h1 h2 h3 h4 h5 h6 Plus a few very reasonable extras: i b cite del ins dl dd dt Attributes that should be allowed: a: href title img: src alt title ol: start blockquote: cite That’s the minimal reasonable set, I think. You may or may not want to also whitelist the table-related tags: table tr td th tbody tfoot thead caption Most of their possible attributes should be allowed in that case. For those, you’ll need to tidy the HTML, not just scrub it, else people will be able to break your layout in malicious ways. You ***DON’T*** want to whitelist the `style` attribute under any circumstances, unless you also have a very very very careful CSS scrubber, because otherwise it’s possible to inject Javascript that way. You’ll also want to validate `...@href` values to keep people from putting `javascript:` URIs or similar foolishness in there. If in doubt, allow too little. That’s the main considerations out of the way. Personally I’d also whitelist `small` and `big`, much like `i` and `b`. You need the latter because `em` and `strong` are wrong to use for some well-reasoned formatting that isn’t emphatic (such as italicising names in citations) – likewise, if you only leave the header tags for smaller/bigger text, people will abuse them for setting large or small text that’s not a headline. For similar reasons, I’d also whitelist `tt`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
* Seumas Mac Uilleachan seu...@idirect.ca [2010-03-24 01:30]: Elastic tabstops would certainly make my pseudo-table much cleaner. Would make creating such a table a breeze without requiring special markup. Is this idea actually catching on Yeah, elastic tabstops solve this problem in a fundamental way. The problem is they’re a boil-the-ocean solution, they require support in almost all tools that will touch the document in question. That’s a very high activation energy barrier… you’ll need a catalyst to get them adopted, eg. a new OS/platform that fully supports them from the get-go – essentially you need an Apple to throw their weight behind it. like Sony Beta - a better solution that no one will buy into? Myth. Betamax was inferior to VHS in significant ways, even if it had an obvious advantage in picture quality and cassette size. The market decided that people prefer VHS’ mix of good and bad to Betamax’ mix of good and bad. End of story. It’s like saying webmail is inferior to desktop mail clients. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
* David E. Wheeler da...@kineticode.com [2010-03-20 23:05]: I'm pretty happy with MMD definition lists (with s/:/~/g) I tried to like them. and with psql-style tables (mostly implemented in Markdent::Dialect::Theory. I find them both esthetically pleasing. They look OK but are a pain to edit. (I haven’t seen a table syntax that I find easier to edit than raw HTML. Well, the fact that Markdown won’t touch the contents makes them still a pain.) I think this editing|reading tension is fundamental, therefor not resolvable. * Sherwood Botsford sgbotsf...@gmail.com [2010-03-20 23:35]: G. K. Chesterton commented, If something is worth doing, it's worth doing badly Only within limits. I like MMD's table syntax. Not perfect. Still a pain to construct, especially if you want to keep the notion of having to look reasonable as plain text. But it *really* beats tablethtd.../thtrtd/td.../tr.../table To look at? Beats it. To write? Not hardly. Esp. if you leave off the closing tags, as I do these days when I write tables in Markdown documents. At this point I can do it with template toolkit and include files, but it's more than a bit rube-goldbergish. In the league with programmable candle powered hydralic peanut butter spreaders. Actually include files are how I would suggest you do that. Better yet use a Markdown implementation where you can pass a prepopulated table of link references (so that the Markdown formatting won’t have to parse the same 1,400 link references over and over). Easy way to modify the behaviour with certain tags. One of the things I want is some way to make it easier to tell Markdown to re-engage inside block tags, in a less klunky fashion than Markdown Extra’s (I think?) markdown=1 pseudo-attribute. I don’t have a good idea for this, though. I wouldn’t want any configurable behaviours, though. To me it is a very important point that you can take a Markdown document from one environment to another without breakage. * Seumas Mac Uilleachan seu...@idirect.ca [2010-03-21 00:45]: I hear constantly about needing Gruber's blessing for any overhaul or changes to Markdown. Why? In case you are referring to my own recent mail, I never said it needs *Gruber*’s blessing specifically. What it does need is one central voice. If you think it doesn’t, then ask yourself why all of the reimplementations have added their own features, yet none of them have copied each other. Except that several of them have copied Markdown Extra. As it happens, Michel Fortin had some blessing from Gruber on several of his efforts. Coincidence? No one needs permission or blessing to fork Markdown. Many people have done it. But that’s the point. To get more than Just Another Fork, it neds to have weight of voice to bring all the other forks together behind it. The goal of markdown is readability. There is no such thing as a readable html table. I would argue that tables are a useful enough feature to include. Whether it is done badly or well is often subjective. At the minimum a simple table format would be important to me (not requiring spanning cells or complex table layouts). Tables are the easiest way to list corresponding values or data that they really should be somehow included. The problem with tables as I see it is as above: I think that tables fundamentally cannot be both easy to edit and easy to read within the constraints of plaintext. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
* Lou Quillio pub...@quillio.com [2010-03-20 00:55]: Markdown's dead? Absurd. Obviously. That’s why no one said that. Markdown *development* is dead. (Straw men are easy to clobber.) Markdown's huge, and in the form of PHP Markdown Extra is basically done. Done != dead, done == problem solved. Fact: the latest Gruber release is a beta. Fact: the latest official Gruber release is missing features that Gruber himself uses. You can argue about whether this means “done” – I see “scratches my itch so I lost interest” –, but you cannot argue the facts. Personally I think Markdown is still missing a lot of fit and polish that could make it much (subtly) nicer still. (Eg. I’m tired of using `!-- --` lines as a crutch to force consecutive, separate blockquotes and lists to be recognised as such.) What it’s not missing is big constructs. (I believe tables and definition lists can only be done badly, and so should not be done at all.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Media type for markdown?
* Dietrich Epp d...@zdome.net [2010-03-06 22:40]: I think it's about time that markdown had its own IANA media type. Most people just use text/x-markdown, I think. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
* david parsons o...@pell.chi.il.us [2010-03-06 05:25]: In article 20100306020548.gb...@protagoras.phil.berkeley.edu, John MacFarlane markdown-discuss@six.pairlist.net wrote: `` a```a `` should render as codea```a/code Now that's a defect all right. It looks like the reference matches any run of ticks, not just the one or two that I read from the standard. According to the spec it *is* supposed to match any number of ticks – but they are supposed to be the *same* number on both ends. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
* Fletcher T. Penney fletc...@fletcherpenney.net [2010-03-06 00:00]: The point is that each of these variant forms of Markdown evolved to scratch someone's particular itch. As indeed did Markdown himself. Once it scratched John’s own itch well enough, he lost the compulsion to improve it. Which I can relate to very well – a lot of my personal projects end up this way. The problem we are having is that by virtue of being the principal designer of Markdown, he is also the only one with the authority to set a direction and have all implementations unilaterally follow it. Michel Fortin is probably the only one in an at all comparable position. Personally I find most extensions to Markdown lacking in that ineffable spirit that ties Markdown together. But I’m pretty sure that the designers of these extensions disagree, and would in turn find my proposals lacking. And if that is the case, then I’d be even less likely to want anything that any likely committee would cook up. This is why the fact that Gruber himself no longer participates causes a problem for everyone else who is invested in Markdown: there is no longer a central voice. But Gruber created what he did, and shared it, and he marketed it (and very successfully, as we all are proof of) for what it was. That no one else has had the same success in pushing their own evolution of the format does not oblige Gruber to anything. If Markdown is to evolve, this is the problem that needs to be solved: it needs a principal designer with a good enough sense for its spirit and enough of a voice to gain the authority to have his or her mandates followed. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: multiline header
* Waylan Limberg way...@gmail.com [2010-03-02 18:25]: To be honest, I can't think of any elegant way to do multi-line setext headers, Exactly. but multi-line hash headers should be easy. I’ll agree with that. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: multiline header
Hi Alexandre, * Alexandre Leray alexan...@alexandreleray.com [2010-03-01 22:35]: I have a document with quite long titles and I was wondering if it was possible to hard-break them: e.g.: This is a veeery long title === would be This is a veeery long title == Right now it produces two h1/ tags. you could always fall back on HTML: h1This is a veeery long title/h1 If you need inline formatting inside the header, then hopefully your implementation supports the `markdown` pseudo-attribute: h1 markdown=1This is a very, very, very, *very* long title/h1 * Waylan Limberg way...@gmail.com [2010-03-02 00:05]: And that's the problem, lazy authors have been relying on the existing behavior for so long that changing it now could break thousands of existing documents. This sort of laziness seems like a design goal of Markdown, not a bug in its users. * Tim Visher tim.vis...@gmail.com [2010-03-02 02:30]: If you're desperate for a multi-line header in markdown, you have a few options. 1. Use Non-semantic markup directly in the document: h1This is line one of abr / very long header!/h1 That's not recommended simply on the grounds of it not being semantic and no one likes non-semantic markup. ;) Non-semantic, says who? More importantly, the problem was not to display a header across two lines in the rendered document, it was being able to write the header across several lines in the source document (and still have a single tag in the rendered document), so your solutions aren’t. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
* Suraj Kurapati sun...@gmail.com [2009-09-09 06:20]: What if Markdown used Unicode characters to express tables in this manner? Then I would still write my tables using HTML tags. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: A Modest Definition List Proposal (David E. Wheeler)
* Aristotle Pagaltzis pagalt...@gmx.de [2009-02-28 16:18]: You can make a lot easier to write with a very simple tweak: Sorry for the noise. Someday I’ll consistently remember to read the whole thread before following my impulse to respond. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: A Modest Definition List Proposal
* David E. Wheeler da...@kineticode.com [2009-02-19 02:00]: Yeah, okay. […] D’oh! Oh yeah! Told you it is a thorny problem. :-( It *looks* simple, yeah… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: use re 'eval' error
* Louis-David Mitterrand [EMAIL PROTECTED] [2008-10-23 13:55]: What is the fix? You have to patch Text::Markdown to add that line to the block the regex is in. I see you have already filed a bug against Text::Markdown, excellent. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-09-09 07:45]: jacob said: This entirely contradicts Markdown's purpose and philosophy. and aristotle agreed: That is my opinion too. it _might_not_ (or might) be in alignment with the purpose and philosophy of markdown, but hey, it does not contradict it, _certainly_ not entirely. this is what gruber says under markdown philosophy: Markdown is intended to be as easy-to-read and easy-to-write as is feasible. Readability, however, is emphasized above all else. he continues: A Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions. if the intent is ambiguous -- and it _clearly_ is ambiguous, since no one here can state unequivocally what was meant, which is why there are competing interpretations at work -- then the document certainly will not be _readable_, let alone publishable as-is. so it's out of the realm of the philosophy. With due respect I have to say it seems to me you are utterly misinterpreting the second paragraph you quoted. My reading is that “publishable as-is” refers to it not “looking like it’s been marked up with tags or formatting instructions.” Simply put, all it says is that Markdown documents should not look like code – unlike HTML, which does. Furthermore, regardless of whether you are claiming that a document is readable or not, I know that as a human I have no trouble extracting some meaning from any of the examples given in this thread. Certainly if they contained real text, I would have even less trouble to understand what the author meant, based on contextual cues like, oh I dunno, *what the text says*. My interpretation of the Markdown philosophy is that plaintext documents have inherent meaning to humans, and the rules of the syntax should be designed to infer that meaning correctly. You’ll recall [1] that John’s motivation for designing Markdown was the tedium of the common tasks in writing HTML by hand – putting in tags for paragraphs, emphasis, quoting, etc. “It’s 2004. Shouldn’t your computer be able to determine where you’ve written paragraphs and sub-heads?” Obviously, the formatter should try its best to reflect the structure of the written prose with the appropriate means of HTML. Imagine that someone was nice enough to buy you a gift: an original typewritten manuscript for a classic novel. Let’s say Fitzgerald’s “The Great Gatsby”. You could sit down with this manuscript and read it, straight through, and get pretty much the same reading experience as you would when reading it in the form of a nicely bound and typeset book. Yes, it would all be set in the typewriter’s smudgy fixed-width Courier-esque typeface, with underlining instead of italics, etc. — but the words would still flow, from page to mind, just as Fitzgerald intended. Is there such a thing as an invalid classic novel? So how can there be such a thing as an invalid Markdown document? The quote from Stanley Kubrick I used to start this article is one of my very favorites. When you write and read text that’s marked-up with HTML tags, it’s forcing you to concentrate on the *think* of it. It’s the *feel* of it that I want Markdown-formatted text to convey. I can find no way to reconcile the above with your claim that ambiguous writer’s intent puts a source document outside the realm of Markdown’s philosophy of publishability. [1]: http://daringfireball.net/2004/03/dive_into_markdown Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* Jacob Rus [EMAIL PROTECTED] [2008-09-08 22:00]: [EMAIL PROTECTED] wrote: if one can do all those things another way, then i wouldn't treat this as _any_ of them. just leave it as-is, so people get channeled into doing each of those things correctly. [...] i think, in the long run, that makes it easier for people, because it demands that they be clear in their thought. if they are ambiguous about what they want, do nothing! This entirely contradicts Markdown’s purpose and philosophy. That is my opinion too. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* Waylan Limberg [EMAIL PROTECTED] [2008-09-08 17:15]: On Sun, Sep 7, 2008 at 10:14 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: Any inferred nesting would have to subordinate them to an implied 3rd item in the surrounding unordered list that is not written out in these examples – semantically equivalent roughly to this: - foo - bar - 1. baz 1. quux - qux Not necessarily. Take the following example (with 4 spaces before item two): - one 2. two With the exception of Maruku (which falls flat on it's face here), every implementation consistently renders this: ul lione ol litwo/li /ol /li /ul While I hate to deflate any argument against option B, the fact is, there doesn't have to be any implied 3rd item in the surrounding unordered list. I am not sure where you have argued anything at all? My entire point is that as a human reader I see the last item in my example lists as really belonging to the same list as the first two items, even though there’s another list in the middle. I don’t think there’s any strong argument to be made that this is not the case. Actually I see *all* the items as belonging to the same list. The two numbered ones just happen to have a relationship to each other that the others don’t share. But there is no way to express that in Markdown. Because there is no way to express that in HTML. Lists can only be ordered or not as a whole. The example I gave with the implied 3rd item in the impliedly outer list is just an attempt to convey roughly the same semantics in HTML and Markdown as what I see, but it is not an argument that this is how it should actually be rendered, since it wasn’t written that way by the author. The only available option in HTML, which is what Markdown should do IMO, is simply render this as three distinct lists. However, without the indentation, I don't think it's clear to the casual reader that that should be a nested ordered list - which I've already discussed in my previous comment. Honestly I don’t care. If you insist on more indentation for a nested list, then imagine that I had used more indentation. It doesn’t matter for the purpose of the argument. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* Yuri Takhteyev [EMAIL PROTECTED] [2008-09-08 19:40]: Between A and C it seems that A wins the popularity contest 7:3 ((John skipped markdown.lua's vote for A). So, A also wins the plurality vote even if B is not eliminated. So, I would declare it the right behavior. Sure, but the implementors never talked about this. They just had to resolve this case individually. And what do you do when you don’t feel strongly about it? You look at what Markdown.pl does. Which does A. It doesn’t at all seem surprising to me that A wins in that contest. But in actual discussion here on list, as far as I saw, with the exception of “Bowerbird” who made up option D, everyone voted for C, with some of us calling A a reasonable secondary option. (Did I misread the discussion?) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* Waylan Limberg [EMAIL PROTECTED] [2008-09-08 15:30]: Although I seem to recall talk in the past about the following: 1. foo - bar - baz Where the first item sets the list as ordered, and the rest just defines the items. The argument made was that the author could then reorder, insert or delete any random item without feeling the need to renumber the items. I thought this was attractive, but it occured to me that whenever you want that, you can get it just as well by instead writing the list this way: 1. foo 1. bar 1. baz Personally, I'm the type that's going to renumber the items anyway If you kept Markdown documents in a version control system, you would avoid that. :-) (Renumbering items when shifting them around can cause a lot of noise in diffs from spurious changes.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
* John MacFarlane [EMAIL PROTECTED] [2008-09-08 03:25]: I'm curious how people think the following *should* be interpreted: - one 2. two For the purpose of the argument I’ll expand a little with more realistically likely examples: * foo * bar 1. baz 2. quux * qux - foo - bar 1. baz 1. quux - qux In those examples I see the 3rd and 4th items as having an implied relationship that is stronger than among the rest of the items, but I do not see those two as subordinate to the 2nd item. Any inferred nesting would have to subordinate them to an implied 3rd item in the surrounding unordered list that is not written out in these examples – semantically equivalent roughly to this: - foo - bar - 1. baz 1. quux - qux Therefore, I would say these should be rendered as either three separate lists or as a single unordered list, but definitely not as an unordered list with an ordered list nested inside its 2nd item. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Syntax Questions
* Michel Fortin [EMAIL PROTECTED] [2008-07-22 12:40]: Have you considered what will happen to code blocks with `nl2br`? That can be fixed by *replacing* newlines with break tags so there aren’t any literal linebreaks. View Source won’t be pretty but the browser rendering will be correct. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Syntax Questions
* Jurgens du Toit [EMAIL PROTECTED] [2008-07-21 09:05]: I don't think that if something is difficult to test, it shouldn't be implemented. You mean it’s fine for people to give you software that might or might not work, and they don’t know which? What happens if you report a bug and they can’t test whether their bugfix breaks previously working stuff? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: mkhtml.py: writing HTML documents in Markdown
* Kragen Javier Sitaker [EMAIL PROTECTED] [2008-06-08 18:00]: On Sat, 7 Jun 2008 17:42:53 +0200, Aristotle Pagaltzis wrote: * Kragen Javier Sitaker [EMAIL PROTECTED] [2008-06-07 09:40]: Stylesheeting comes naturally. I just put a `style` element at the top with a few lines inside of it to format nicely. Note that Markdown ends up wrapping `link` and `style` in `p` tags, arguably erroneously. What, is Markdown supposed to know that those elements are neither block-level nor span-level markup? In fact it is – or to phrase the statement more appropriately, it is supposed to know that wrapping such elements in `p` tags is not a useful thing to do. It already avoids wrapping block-level tags in paragraphs; there is no reason not to extend that list to also contain all the elements that may appear in the head of an HTML document, even though they are nominally invalid in the body. Of course, neither tag has any business being in the HTML body; they should both be in the head. Since you’re loading BeautifulSoup anyway, you probably want to include that as fix-up step in your postprocessing. Yeah, I've been planning to do that, but didn't get around to doing it before sending it out. (I also have this theory that I'll be a happier person if I don't spend too much time on inventing private markup languages, and that makes me perhaps unreasonably reluctant to add extra postprocessing steps, even when the alternative is ill-formed HTML.) I agree with that theory, which is why I use Markdown despite the minor (and a few less minor) things I dislike about it. Attaching some light postprocessing to Markdown to add support for small missing bits seems like a much better approach to achieve both satisfaction and an absence of unhappiness. I try to write code only when I can’t help it… Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: mkhtml.py: writing HTML documents in Markdown
[Note to markdown-discuss readers: for context see http://lists.canonical.org/pipermail/kragen-hacks/2008-June/000488.html] * Kragen Javier Sitaker [EMAIL PROTECTED] [2008-06-07 09:40]: Stylesheeting comes naturally. I just put a `style` element at the top with a few lines inside of it to format nicely. Note that Markdown ends up wrapping `link` and `style` in `p` tags, arguably erroneously. Weirdly, it looks like Python-Markdown should avoid that mistake: * http://babelmark.bobtfish.net/?markdown=%3Cstyle%3Efoo+%7B%7D%3C%2Fstyle%3E * http://babelmark.bobtfish.net/?markdown=%3Clink+%2F%3E But at the top of http://canonical.org/~kragen/crywrap.html the problem shows up anyway. Of course, neither tag has any business being in the HTML body; they should both be in the head. Since you’re loading BeautifulSoup anyway, you probably want to include that as fix-up step in your postprocessing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Optional features (was: Markdown Extra Specification (First Draft))
* Yuri Takhteyev [EMAIL PROTECTED] [2008-05-23 08:35]: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-05-23 05:40]: I also agree with your opposition to them; if anything, one should filter the *output* of a Markdown-to-HTML conversion so that it won't matter whether people write literal `em` tags or use asterisks. This is true in theory... I actually just recently write something along those lines in Lua [1] to use with my Lua wiki. The idea is to do as you suggest: Convert from MD to HTML first, then filter the HTML. To make it safe, I parse HTML as XHTML and complain if it doesn't parse. Hence a problem: if the user screws up with their HTML (and my filter is pretty unforgiving), it becomes hard to communicate to them what went wrong. I can tell them where there is a problem in the overall HTML, but this doesn't help much, since the user didn't know there was all of this HTML to begin with. It seems to me that filtering is a red herring in your case. If you want to allow users to enter literal tags, you will have this problem whether you filter the ultimate output or not. There is no easy way to show them where the problem occurred relative to the input that they provided, or to show them the content with just _their_ HTML escaped. So, a good solution in Markdown itself actually would be a good thing. If your XHTML parser has a streaming input mode, you can couple your Markdown converter directly to the XHTML parser and feed the HTML output to it as you go. If the XHTML parser throws a well- formedness error, you can then relate it to the vicinity of the last Markdown chunk you converted to HTML and passed into the XHTML parser. It will sometimes be an earlier chunk; eg. if the user writes `nbsp` (notice the missing semicolon) and this is exacly at end of string in the HTML chunk you pass to the XHTML parser, then the XHTML parser will have to wait until the next chunk before it can decide that that entity is broken. If you don’t want to couple the Markdown converter with an XHTML parser that closely, it’s still possible to do this, but the Markdown converter will have to be able to accept streaming input itself and will need to generate output sufficiently frequently that you can track the correlation of input and output with a useful amount of precision. The glue code that combines the Markdown converter with the XHTML parser will have to do some relatively hairy (tho not very complex) bookkeeping in that case. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Optional features (was: Markdown Extra Specification (First Draft))
* Yuri Takhteyev [EMAIL PROTECTED] [2008-05-24 21:35]: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-05-24 11:15]: If your XHTML parser has a streaming input mode, you can couple your Markdown converter directly to the XHTML parser and feed the HTML output to it as you go. If the XHTML parser throws a well-formedness error, you can then relate it to the vicinity of the last Markdown chunk you converted to HTML and passed into the XHTML parser. I am not quite sure what you mean, but Markdown documents can't always be processed on a chunk by chunk basis. Consider: Here is a [link][id]. ... 100KB of text... [id]: http://example.com/ Optional Title Here This document cannot be processed correctly unless it's considered all at the same time. Good point, so streaming the Markdown input is not possible. But that doesn’t mean you can’t generate the output piecemeal and also feed it to the XHTML parser that way. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Optional features (was: Markdown Extra Specification (First Draft))
* Sherwood Botsford [EMAIL PROTECTED] [2008-05-07 22:10]: THAT said, however, maintaining perfect backward compatibility slows down progress. I don’t know. It seems to me perfect backward compatibility is not even possible, considering that Markdown.pl is not set in stone (John takes bug reports and writes fixes, every so often) and yet is not formally defined anywhere. As such, there is no way to say what is backward compatible and what isn’t. I think at most, backcompat for the purposes of a spec for Markdown can only be defined as targetting a particular feature set, but not an exact implementation of it. That is, after all, the entire reason for the spec effort in the first place. Can markdown extra have a configuration file: The default behaviour is to emulate markdown. The configuration file allows for new features that don't fit well into the old set. Optional features are dangerous and impede interoperability. Everyone who ever thinks about chipping in on the design of a spec should read [section 5 of RFC 3339][1]. That RFC is a spec for a particular datetime format, but section 5 is largely agnostic of the nature of the format, and lays down the principles according to which the design decisions for this format were made. [Section 5.3][2] is the part with direct relevance to your stipulation, but the entire section is readworthy. [1]: http://tools.ietf.org/html/rfc3339#section-5 [2]: http://tools.ietf.org/html/rfc3339#section-5.3 One problem is that every new option leads to a geometric increase in the number of feature combinations that have to be tested. Another issue is that Markdown is a document format. If it has many optional features, what are the chances that if I send you a document ostensibly written in Markdown that will work in your implementation of Markdown exactly as it did in mine? You really really don’t want to have to wonder. This was a major reason why SGML mostly failed, f.ex., and only gained traction when it was restandardised as XML. SGML had legions of optional author-friendly features that it made it an extreme amount of work to implement a parser that correctly implemented the entire spec. The XML working group sat down and basically chucked out 95% of the optional features and made the rest mandatory. The rest is history. Optional features in a document format are an invitation for interoperability problems. Since the entire point of the Markdown spec effort was to reduce existing interoperability problems, I strongly advise that as little as possible in the spec be made optional. Ideally, nothing would be. It is, mind, perfectly fine to have two (or maybe three?) specs of which one is a superset of the other, as seems to be Michel’s current thrust with Markdown vs Markdown Extra. Assuming that no feature in either spec is optional, that means you would be able to expect Markdown Extra documents to work in all Markdown Extra processors, and all Markdown documents to work in all Markdown and Markdown Extra processors. The scope of the problem is much smaller in such a scenario, enough so to be perfectly tractable. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
On ampersands in query strings (was: HTML entities in URLs and urlencoding)
* Waylan Limberg [EMAIL PROTECTED] [2008-04-01 03:50]: As far as I can tell, the amp; breaks the query string. No, it doesn’t, as you found out. However, on a tangential note: if you write web apps, *please* make sure that you support the semicolon as a query parameter separator as well as the ampersand: http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2 More importantly, please **please** make sure that the URIs your code generates use semicolons rather than ampersands. Semicolons need not be escaped in HTML and XML, which makes copy-pasting users much less likely to produce invalid markup regardless of the context they’re working in. Even though this W3C recommendation is over a decade old, use of ampersands in query strings persists. (In fact, PHP not only does not emit URIs with semicolon-separated query strings, by default it cannot even parse them! You need to set an unbreak-me config option to make it recognise the semicolon.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: [ANN] Babelmark
* Tomas Doran [EMAIL PROTECTED] [2008-03-23 13:10]: I've got [Devel::Cover] to measure coverage, and it (on [my trunk], which is close to 1.0.17) says that my coverage is almost perfect: Filestmt bran condsub time total -- -- -- -- -- -- blib/lib/Text/Markdown.pm 99.8 94.2 72.0 100.0 100.0 87.0 96.9 Which is *just wrong* - as I know there are piles of corner cases that my tests don't adequately cover. :( Probably a lesson to point out that automated coverage analysis isn't too useful in some cases... [Devel::Cover]: http://search.cpan.org/~pjcj/Devel-Cover-0.63/lib/Devel/Cover.pm [my trunk]: http://svn.kulp.ch/cpan/text_multimarkdown/trunk/ Yes, well. If you write one test case that causes the code to perform a particular pattern match, then the match expression is considered covered… even if uses a 500-line regex that parses an entire file format. This problem basically occurs whenever a separate language is embedded into the main code: SQL queries, XPath expressions, templates in some template mini-language, whatever. If the coverage metric doesn’t cross the language barrier right along with the code, it breaks down at these points. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: forking Markdown.pl?
* Tomas Doran [EMAIL PROTECTED] [2008-03-18 13:15]: My preferred solution would be for the 'original' (i.e. daringfireball brand) Markdown to have most of the code in a module called Text::Markdown, but to supply a script wrapper called Markdown.pl which provides the original functionality. This is what I've done in Text::Markdown currently so that people get the best of both worlds. Note that this doesn’t mean giving up ease of installation that people currently get. (Ie. non-Perl people, which is basically every end-user, for whom it is admittedly a burden to install a CPAN distribution, can just drop a file in some directory and maybe +x it and that’s it.) The model here would be Andy Lester’s _ack_ utility (an awesome grep replacement for trees of source code): it’s available from CPAN as the App::Ack distribution written in the regular way, as a module using several other modules and invoked from a small script. Anyone familiar with Perl who knows how to install modules can install this just like any other CPAN distro. But the distro’s build script also has a target that rounds up all the necessary modules and pastes them into the script file, producing a program that needs just perl itself preinstalled on a machine; this is available as `ack-standalone` from Andy’s site for ack. That way, people who don’t know about modules and CPAN and all that can just copy a single file onto their machine and be off to the races. That seems like a perfectly suitable model to handle Markdown.pl. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: on the philosophical aspects of a specification
Hi Yuri, Weylan and Seumas, * Yuri Takhteyev [EMAIL PROTECTED] [2008-03-07 08:50]: *hello **dear* boy** That's a very good question. Here's a counterquestion: what does a human reader see in that text? When I try to look at this with my normal-person eye, what I see here is incorrect markup Sorry, but if you see “markup” (much less “incorrect markup”) you’re not looking at it with a normal-person eye. :-) So, the user will type in something like this and get emhello **dear/em boy**. Not much of a tradegy. They will say, oh, silly me, must have screwed something up. (They did!) Then they'll go and fix it. I am all for flexibility, but not to the point of trying to divine the meaning of ambiguous or ill-formed markup. Only a small minority will do that. Most people most of the time don’t care enough about that particular piece of text to actually fix any small nits in it, any more than they’ll care to fix all of their small spelling and grammar mistakes. (Less, actually.) That has certainly been my experience on wikis and weblogs that use shorthand markups like Markdown. Hence my bias in favour of trying to divine *some* meaning from anything that looks like markup somehow, as long as there is any chance at all that the result won’t be actively contrarian to the user’s wishes. I think any rule would be ok, as long as it satisfies the following criteria: 1. It's _simple_ I think the full rule needn’t be simple; as long as edge cases don’t produce actively contrarian results, it’s OK not to mention how they’re resolved in the interest of simplification. My reg-exp eye says: strong before em (longer pattern first), starting from the right for each. I am pretty sure this rule satisfies 1, 2, and 3. So the spec is going to make assumptions about the method of implementation? Let's stop this non-sense and get back to defining a spec for the _normal_ markdown. What’s the point? We already have one; John Gruber wrote it. Interoperability problems crop up in the edge cases, not the unproblematic stuff. That is what’s important to specify. * Waylan Limberg [EMAIL PROTECTED] [2008-03-06 17:00]: Aristotle Pagaltzis wrote: a human reader see in that text? Based on the visual apperance I think I would make it translate to this: emhello strongdear/strong boy/em Ah, so your assuming the parser should automatically close unclosed tags much as a browser in quirks mode does. No, a browser in quirks mode would not interpret such a construction in the way I proposed at all. Sure, you and I understand how that works, but should we expect authors who are unfamiliar with html to get that? I was precisely trying **not** to think about it in terms of HTML. What I proposed was, as explicitly said, purely based on visual apperance: ,-,-- “dear” is enclosed in emphasis markers v v *hello **dear* boy** ^ ^ `--`- the whole phase is also enclosed in emphasis markers And that’s why I prosed the translation in question. It’s funny that everybody assumed I was thinking in terms of some kind of error-correcting parser. I didn’t even consider how this would be implemented while I was mulling over what to do with that fragment. emhello strongdear/em boy/strong Yeah, we could give them output that displays as they expect and fix it under the hood by doing: emhello strongdear/strong/emstrong boy/strong But, the output **I** would expect is one of: emhello /ememdear/em boy** emhello **dear/em boy** *hello strongdear* boy/strong I could live with that one: emhello **dear/em boy** That makes the least non-sense, of them all. But it would mean that a lot of people will leave visible slop in their Markdown-formatted text because they won’t care enough to fix it. Remember that even with the output I proposed, it’s not hard for someone to get *any* of these other interpretations, as long they actually care enough to explicitly write their markup so as to produce that. In my mind I keep going back and forth between the three and can never decide which the author intended. Finally, I cringe as I realize they probably intended what Seumas suggested. Well, clearly, they meant to nest a few kinds of emphasis. They probably wrote it that way either because they were thinking in terms of markup and wanted overlapping regions, in which case they can still do that with a bit more effort. Or they wrote it hastily without caring a whole lot about the output; in which case my proposal would at least keep markup slop out of the output. To me, that is an important factor that seems to be ignored by some here. Sometimes, IMO, the best thing to do is to pass the markup through as literal text and give the author a clue that his formatting is unclear! Again, that works if the author cares. If they don’t, it means the output will be ugly
Re: on the philosophical aspects of a specification
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-03-03 23:45]: Is it possible for everyone to agree in all cases about how the user’s intent should be teased out? Clearly it is conceivable that enough effort could be made to write all agreements down. And if you write down what intent should be teased out of particular inputs, what have you created but a spec? And if the effort has been made to agree on all possible cases, would this spec not be unambiguous? And is it not yet obviously the case that such a spec would not need to be inflexible about the syntax it admits? Why then does the fallacious argument that a spec would represent a loss for the user continue? aren't you loading the dice by labeling it as fallacious? No. The reasoning I outlined in questions [I’ve taken the liberty to re-insert the quotation you elided] shows that the premises do not support the argument. That means, like it or not, that the argument is fallacious. Sorry. I can’t change that. i'm not necessarily arguing that _any_ spec would do that. but some might... most especially by some implementers... Then those specs would not describe Markdown. As I understand, the current discussion is about writing a specification for Markdown, not for some other markup language. If those “some” implementors want to write a specification for something other than Markdown, they are welcome to do so, but they and their spec are irrelevant to the ongoing discussion. and according to markdown, users can't be wrong, can they? Users can very well be wrong according to Markdown. As John has said, if a human would have trouble figuring out what structure some piece of text is supposed to signify, the computer can be forgiven for likewise failing to infer a useful meaning. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: on the philosophical aspects of a specification
* Michel Fortin [EMAIL PROTECTED] [2008-03-05 05:10]: A better question is what to do with this: *hello **dear* boy** That’s a very good question. Here’s a counterquestion: what does a human reader see in that text? Based on the visual apperance I think I would make it translate to this: emhello strongdear/strong boy/em Really. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: spaces and newlines before list markers (was: evolving the spec)
* Yuri Takhteyev [EMAIL PROTECTED] [2008-03-03 02:20]: What about setting value on each li instead? Equally deprecated. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: on the philosophical aspects of a specification
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-03-03 07:00]: i would prefer that implementers get more sophisticated about teasing out the user's intent in ambiguous cases. If every implementor teases a different intent out the same document, the user loses. Is it possible for everyone to agree in all cases about how the user’s intent should be teased out? Clearly it is conceivable that enough effort could be made to write all agreements down. And if you write down what intent should be teased out of particular inputs, what have you created but a spec? And if the effort has been made to agree on all possible cases, would this spec not be unambiguous? And is it not yet obviously the case that such a spec would not need to be inflexible about the syntax it admits? Why then does the fallacious argument that a spec would represent a loss for the user continue? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: spaces and newlines before list markers (was: evolving the spec)
* Yuri Takhteyev [EMAIL PROTECTED] [2008-03-01 00:20]: My suggestion would be to actually restrict the range of what is turned into ordered lists, either by requiring that ordered lists start with 1., or that they have at least two items with consecutive numbers, or even to require both. Not both, but lists not starting at 1. having to have more than one item is a nice idea for solving the problem. I frankly don't see a point in allowing the user to number their list items starting with an arbitrary number if those the list will start with 1. when displayed to the viewer anyway. This is actually my second biggest complaint with Markdown. As I understand, John was originally going to allow numbered lists to start at numbers other than 1, but then discovered that the HTML4 WG labelled the `start` attribute of lists deprecated, so he removed this feature. I find the WG’s decision utterly baffling and wrong-headed. *How on Earth* is that information presentational?! So while I don’t disagree with the basic desire to output valid HTML, I think John’s decision in this one case was mistaken. IMO, in this one case Markdown should do what is sensible, validation be damned. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: evolving the spec (was: forking Markdown.pl?)
* Waylan Limberg [EMAIL PROTECTED] [2008-02-29 17:00]: As implementors, we want a strict spec because it's easier to implement, but that does not always result in easier to read and/or write. You have “strict” and “simplistic” confused. If the spec for the syntax is rigorous that does not mean the syntax has to be rigid. It just means it is well-defined how an implementation of Markdown should parse particular constructs. That has nothing whatsoever to do with the flexibility in the syntax. The current syntax summary leaves a lot of grey areas where you could reasonably do any of several things. The upshot is that the whenever someone implements Markdown from scratch, most likely his implementation *does* do something other than the reference implementation for that case. And experience confirms this. Therefore, I don’t quite follow this argument: Now, before you all write me off as insane, this is actually why I think Markdown 2.0 is a good idea. By moving to 2.0, we don't have to worry about backward compatibility (Markdown 2.0 should not allow those 3 spaces). You *already* can’t move documents from one implementation to another without expecting breakage. Heck, you can’t move them from one version of an implementation to a newer version of the same implementation without expecting some breakage. The question is, how much breakage would conformance to the more rigorous spec cause? If it isn’t much: do you think any users will care about the subtleties of Markdown 1.0 vs Markdown 2.0? Don’t you think they’ll blithely grind their Markdown 1.0 documents through a Markdown 2.0 processor if this works most of the time? If it would cause a lot of breakage: isn’t that maybe because a lot of people actually like this “unintended feature”? Does that not possibly mean that it’s worthwhile to try preserving as an actual feature in the spec? (If several implementations have the same accidental feature, particularly?) Remember, it’s always easier to change the spec to fit existing fact rather than the other way around. (Cf. HTML5.) Now if you insist on causing so much breakage that people *cannot* just grind their 1.0 documents through a 2.0 processor: what do you expect does this imply for the adoption of 2.0? Don’t you think it would rather cause a lot of people not to “upgrade” the way they did with XML 2.0 and Windows Vista? Some upgrades those were. Now turn around and consider the two calls you make in relation to each other. I don’t know about you, but it seems contradictory to me that first you argue for a spec that allows documents to be written in a very lax syntax, then turn around and backward compatibility should be abandoned so that we can have the freedom to reduce the flexibility of the syntax. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: forking Markdown.pl?
* Joseph Lorenzo Hall [EMAIL PROTECTED] [2008-02-28 00:40]: As many of you know, when a piece of open-source software languishes with bugs for 3 years it's often forked No, that’s not what I know. What I know is that projects get forked if they have developers who irreconcilably disagree with the current maintainer about the future direction of the project. (If the current maintainer has gone AWOL, that’s merely a special case of this scenario.) But the new maintainer comes first, and the decision to forks comes afterwards, because without a new maintainer, there is no fork. Therefore: I'm not volunteering (I'd be horrible)... just seeing if it's time to have that discussion. If you’re not volunteering and no one else does, then “having that discussion” is pretty pointless. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Syntax for extensions
* Florian Lindner [EMAIL PROTECTED] [2008-02-13 20:35]: Is there any special syntax that should be used for such 3rd party extensions? How would you do it? I’ve found that if you don’t mind a somewhat nasty-looking syntax, plain links are a nice extension point that can be used for simple functionality without adding any new syntax to Markdown. F.ex. to support abbreviations, I invented an `abbr:` link scheme, so that I could write [RDF](abbr: Reality Distortion Field) which Markdown would then translate to a href=abbr: title=Reality Distortion FieldRDF/a which a trivial bit of XSLT would turn into abbr title=Reality Distortion FieldRDF/abbr Pretty? Not at all… but it worked, it was completely independent of Markdown as such, and also completely independent of any one particular Markdown implementation. In your particular use, the use of the URI would not even be a hack the way it was for mine. Just write your image tags something like so:  and then use script to replace any `img src` URIs in the output that have the `replace:` scheme with whatever post-determined URI is appropriate. You don’t need to meddle with Markdown at all. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown MIME type?
* Thomas Nichols [EMAIL PROTECTED] [2008-02-04 14:10]: When this came up on the list before I think there was a consensus that `text/x-markdown` is usable -- possibly with a URI to identify the Markdown syntax used. Did I understand that correctly? Yes, you did. Using a type with a subtype starting with `x-` is permissible, and in absence of a registered MIME type, the only thing that third parties can do. Note [RFC 4288, section 3.4][1], though: However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both x- and x. forms is discouraged. [1]: http://tools.ietf.org/html/rfc4288#section-3.4 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown MIME type?
* Petite Abeille [EMAIL PROTECTED] [2008-02-03 17:55]: What MIME type do people use for Markdown? Regrettably, there still isn’t one registered for Markdown. If my reading of [RFC 4288] is correct, John shouldn’t have any trouble registering eg. `text/vnd.daringfireball.markdown` using the application form at http://www.iana.org/cgi-bin/mediatypes.pl. (Most of the “mandatory” fields in that form apply only to MIME types registered in the standards tree, not the vendor tree.) Hint hint, nudge nudge. [RFC 4288]: http://tools.ietf.org/html/rfc4288 text/markdown? text/plain? Suggestions? I end up using `text/plain` most of the time because browsers throw up a download box whenever they encounter an unknown MIME type, even though [RFC 2046] explicitly says they should treat any unknown `text/*` MIME type as `text/plain`. [RFC 2046]: http://tools.ietf.org/html/rfc2046 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
