Re: HTML Tags = Markdown Quick Reference @ Write Kit
It is vary unusual for Markdown parsers to return b and i tags. Usually, strong and emphasis are used instead. See Babelmark for an example: http://johnmacfarlane.net/babelmark2/?normalize=1text=*italic*+%26+**bold** Also, most older implementations return XHTML Tags like br / and hr / rather than there HTML counterparts. In the age of HTML5, this doesn't really matter much (for most users), but back when they were first created it was important to having valid XHTLM (the new hotness of the time). Of note is the fact that b and i are not valid XHTML tags (IIRC). Thus the use of strong and emphasis. Waylan Limberg On Aug 4, 2015, at 5:16 AM, Gerald Bauer gerald.ba...@gmail.com wrote: Hello, I've started a quick reference that lists all HTML tag with Markdown short codes [1]. The tags include: HTML| Notes --- | - h1.../h1 - h6.../h6 | Heading 1-6 p.../p | Paragraph br| Hard Line Break i.../i | Italic Text (Emphasis) b.../b | Bold Text (Strong Emphasis) code.../code| Code (Monospace Text) del.../del | Deleted (Strikethrough) Text ul(li.../li)+/ul| Unordered List ol(li.../li)+/ol| Ordered (Numbered) List a href=../a | Link img src=... alt=... | Image (with Alternative Text) table(tr(td.../td)+/tr)+/table | Table precode.../code/pre | Preformatted Code Block blockquote...blockquote | Blockquote hr| Horizontal Rule !-- ... --| Comments Any tags missing? Let us know. Cheers [1] https://github.com/writekit/quickrefs/blob/master/HTML.md ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: HTML Tags = Markdown Quick Reference @ Write Kit
On Aug 4, 2015, at 10:48 AM, Michel Fortin michel.for...@michelf.ca wrote: Le 2015-08-04 à 10:26, Gerald Bauer gerald.ba...@gmail.com a écrit : Thanks great comments. I've update the quick reference and it reads now i or emphasisand b or strong Shouldn't it be em? There's no such thing as emphasis in HTML. You are correct. Sorry, my mistake. Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: Announce: Markdown (extended) specifications
Here is another list of Markdown implementations: https://github.com/markdown/markdown.github.com/wiki/Implementations While both lists contain many of the same items, there are a few unique to each list. Waylan Limberg On Nov 18, 2014, at 7:39 PM, mofo syne mofos...@gmail.com wrote: For list of implementations for markdown: http://www.w3.org/community/markdown/wiki/MarkdownImplementations List of common mark implementations: https://github.com/jgm/CommonMark/wiki/List-of-CommonMark-Implementations Subreddit: http://www.reddit.com/r/LightWeightMarkup/ On Wed, Nov 19, 2014 at 7:16 AM, Piero Wbmstr m...@e-piwi.fr wrote: Hello Jakub, I didn't know this project (I agree with you: there are already too many MD projects ...). I will look at CommonMark in details to see if I may help on this or propose something like a merge of both CommonMark and MarkdownExtended or anything else. By the way, is there a place where all known MD projects are listed ? Thank you for the info. Regards, P. Le 18/11/2014 18:28, Jakub Jirutka a écrit : Hi Pierre, are you familiar with the [CommonMark project](http://commonmark.org)? It’s _de facto_ standardized Markdown with very precise [specification](http://spec.commonmark.org). If you wanna extend Markdown syntax, then I highly recommend to start on top of this spec. No one needs yet another incompatible and ambiguous Markdown dialect, there are too many of them already. Best regards, Jakub Jirutka ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: It's a Markdown processor, right?
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. Waylan Limberg On Sep 7, 2014, at 2:31 PM, Andrei Fangli andrei_fan...@hotmail.com wrote: Sean wrote: I am trying to use uniform terms. An implementation that converts Markdown content to another format--most typically HTML--is called...a Markdown processor, right? I was focusing on naming the software that takes text in format A and outputs it in format B (yep, just that use case). The XML specifications define that a XML Processor is something that recognizes the structure of a XML Document, validates it and offers access to its content (e.g.: by tree traversal since XML is hierarchical in nature). A software that simply translates from format A to B only recognizes, validates the structure of the text in format A and outputs the content in format B. If we were to apply an analogous definition for a Markdown Processor then the access to content is lost because the initial document as a whole is outputted in format B without having the chance to peak at its content. In that case we cannot name that software a processor, it may use one internally to get the job done. In the case of a software that allows visualisation of Markdown documents prior to translation/export, eventually allowing editing, indexing, word count, page count etc., I agree, that no longer can be called a translator because it does much more. That software falls well in the terms of a word processor (specialized for Markdown in this case) as pointed out, however I’m not sure that’s what Sean was asking. This discussion is turning out quite interesting as parsers require a grammar in a formal language (e.g.: BNF) while a processor can be implemented from a description. Andrei Fangli From: Aristotle Pagaltzis Sent: Sunday, 7 September 2014 20:53 To: markdown-discuss@six.pairlist.net * 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
Re: On simplifying table syntax in any future markdown extension. (Use CSV)
On Sep 5, 2014, at 5:28 AM, mofo syne mofos...@gmail.com wrote: The second issue, is that people find it hard to have to deal with formatting the pipes. If alignment of cell data is of no concern to the user, then we should use CSV data as the inspiration. I've long been (openly) of the opinion that tables are not prose, and therefore do not belong in markdown - except to fall back to raw HTML (see the philosophy section of the syntax rules). On the other hand, I recognize that sometimes a simple, unstyled table of simple tabular data has it's place and having to revert to raw HTML is a little much. So, CSV -- I like it. Plain, raw cvs gets converted to a table. That is something I might be able to get behind. Not sure I like your headers though. Why can't they be comma separated as well? Perhaps one character (at the beginning of the first line) could identify that line as a header. Without that character, then you get no header. Yes, that means you loose any ability to style, but I'm okay with that -- use raw HTML if you want more control. Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: On simplifying table syntax in any future markdown extension. (Use CSV)
On Sep 5, 2014, at 8:24 AM, Waylan Limberg waylan.limb...@icloud.com wrote: So, CSV -- I like it. Plain, raw cvs gets converted to a table. That is something I might be able to get behind Note the might there. After further consideration I was a little eager there. This is as bad of a proposal as any other table proposal I've seen. I like the idea behind it, but in the real world it's not practical for the many reasons already stated by others. Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
RE: Moving Markdown towards a standard syntax
-Original Message- From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of John MacFarlane Sent: Thursday, August 14, 2014 2:10 PM To: Discussion related to Markdown. Subject: Re: Moving Markdown towards a standard syntax Here's an attempt of my own, which I've been working on for some time: http://jgm.github.io/stmd/ Interesting. You appear to mostly be tightening up the existing rules, with only a few deviations. I have little of value to say about most of it, so only a few observations follow. Tabs in lines are expanded to spaces, with a tab stop of 4 characters. We strictly enforce this rule in Python-Markdown and I like it, but we have received bug reports from time to time that certain languages require tabs (spaces would be a syntax error). I think makefiles would be the most well-known example. For example, how would you expect someone to be able to copy from a code block in a blog post and paste into a makefile without needing to go back and edit all the whitespace? If they are copy and pasting, they are not likely to be an advanced user and significant whitespace it already one of the most non-obvious gotchas. Just an observation here. The answer isn't clear to me either. I notice that you state that an HTML block ends with a blank line. I have always wished that it worked that way for the very reasons you cited. As you observe, things like raw `pre` blocks can't have blank lines (might want to add comments, processing instructions and CDATA to that list along with workarounds??). Either way is a compromise and it is not clear to me which is the better way to go. A blank line always separates block quotes Brilliant! I absolutely love what you did with how much indentation indicates nesting within a list (for all block elements, not just nested lists). However, I expect most people will have trouble getting it right in practice. And I wouldn't want to write a parser for that. But I sure would enjoy writing lists with it. Two blank lines will end a list. Really? What about a code block nested within a list item that contains multiple blank lines? If it wasn't for that corner case, I would love this two. Or it there an exception for that? Example 198 seems to indicate so, but I don't see it explicitly stated anywhere. Is it for fenced code blocks only (because you can look for the closing fence -- if so, makes sense to me) or does it work with indented code blocks also? Changing the bullet or ordered list delimiter starts a new list. As it should. Also like the start number being set on ordered lists. A backslash at the end of the line is a hard line break. Brilliant! I see you preserved the 'two spaces' rule. You changed some other things (like list nesting) enough that backward compatibility with existing docs shouldn't be a concern. Therefore, I'm not sure we need both. Every implementation should follow your strong/emphasis spec. All implementers go change your implementations now... oh wait, that means more work for me... If I understand you correctly, all autolinks must be surrounded by angle brackets (the right call btw). Perhaps you should include a url **without** angle brackets in your list of not autolinks to make that clear. That must have been am incredible amount of work. I'm only concerned that it's not really markdown anymore. I'd be tempted to take it that extra step and get rid of all the other things that could be slightly better and call it something else. Of course, I don't see some new plain text markup language taking off now that markdown it so widespread. But it is fun to think about. Waylan Limberg ___ 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
On Jul 12, 2014, at 2:52 PM, Michel Fortin michel.for...@michelf.ca wrote: [snip] When you have a question like this, just try it Babelmark 2: http://johnmacfarlane.net/babelmark2/?normalize=1text=%3Cdiv%3E Yes, that's what we all do. And to answer your other question, notice that only two of the implementations on Babelmark2 failed. Remember, most of these implementations were written to be run on web servers. We can't have our web servers crashing just because a user submitted invalid markdown. What a parser doesn't understand is just passes through. What it misunderstands is garbles but it is specifically designed to never choke. As Michel alluded to, most parsers are simply a series of regular expression substitutions which are run in a predetermined order. If a regex never matches a part of the text, then that part passes through untouched. Yes, that means the HTML is parsed by regex - which we all know is a bad idea -- but it is not really parsed in the way that browsers parse HTML. The regex just finds anything surrounded by angle brackets and ignores it. With the exception of the limited block level stuff, we don't even care if there are opening and/or closing tags. Yes, that can result in improperly nested stuff, but that is the authors fault and the parser should not bring the whole server down for that. The Author can (should?) preview in a browser and fix it before publishing. However, I should point out that while the above describes most parsers (as most are more or less direct ports of markdown.pl - which works this way), there are a few that use other methods under the hood. For example, a few generate a parse tree which is then fed into a renderer (I believe Pandoc works like that, which allows it to output many more formats than just HTML), but they are the rare exception. Waylan ___ 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
On Jul 12, 2014, at 6:23 PM, Sean Leonard dev+i...@seantek.com wrote: On 7/12/2014 12:31 PM, Waylan Limberg wrote: On Jul 12, 2014, at 2:52 PM, Michel Fortin michel.for...@michelf.ca wrote: [snip] When you have a question like this, just try it Babelmark 2: http://johnmacfarlane.net/babelmark2/?normalize=1text=%3Cdiv%3E Yes, that's what we all do. And to answer your other question, notice that only two of the implementations on Babelmark2 failed. Remember, most of these implementations were written to be run on web servers. We can't have our web servers crashing just because a user submitted invalid markdown. What a parser doesn't understand is just passes through. What it misunderstands is garbles but it is specifically designed to never choke. As Michel alluded to, most parsers are simply a series of regular expression substitutions which are run in a predetermined order. If a regex never matches a part of the text, then that part passes through untouched. Yes, that means the HTML is parsed by regex - which we all know is a bad idea -- but it is not really parsed in the way that browsers parse HTML. The regex just finds anything surrounded by angle brackets and ignores it. With the exception of the limited block level stuff, we don't even care if there are opening and/or closing tags. Yes, that can result in improperly nested stuff, but that is the authors fault and the parser should not bring the whole server down for that. The Author can (should?) preview in a browser and fix it before publishing. However, I should point out that while the above describes most parsers (as most are more or less direct ports of markdown.pl - which works this way), there are a few that use other methods under the hood. For example, a few generate a parse tree which is then fed into a renderer (I believe Pandoc works like that, which allows it to output many more formats than just HTML), but they are the rare exception. I see. Here is a real-world example of what I was citing: http://johnmacfarlane.net/babelmark2/?text=Hello+I+am+some+*text*.%0A%3Cdiv%3EHello+%3Ca+href%3D%22http%3A%2F%2Fwww.example.com%2F%22%3Ethat+is+nice%3C%2Fa%3E+chance+%26+circumstance%26hellip%3B%0A%0AThe+end. Truly, it looks like there is great diversity in Markdown-land. Ok, so any standard mentioning Historical Markdown cannot say that any particular behavior is normative when it comes to HTML validity. Some check for HTML (island) validity and behave differently; others don't. The end...I guess. Yes, but select normalize (which normalizes insignificant white space in the output), and the number of variations decreases. Unfortunately, there is absolutely no standardization in how the various implementations handle white space (I don't think I've seen two that match exactly in every corner case). Either way though, hit the preview button (top right of output) to see how the browser renders the output and all but a couple render in the browser exactly the same. And that is what makes markdown so great. You don't need to know or understand HTML to write it if you are using markdown. And if you have only an elementary knowledge of HTML, you can break into HTML on those few occasions when markdown won't do what you need. Waylan ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Agreeing on Historical Markdown (was: Re: text/markdown effort in IETF (invite))
On Jul 11, 2014, at 7:20 PM, John MacFarlane j...@berkeley.edu wrote: +++ Sean Leonard [Jul 11 14 01:54 ]: Since we cannot reach consensus on what ought to be Standard Markdown today, can the community reach consensus on Historical Markdown--of which I propose three working definitions? I think the only sensible thing to refer to is John Gruber's Markdown syntax description, which is the canonical reference (even if it is very incomplete on the details). Markdown.pl 1.0.1 and 1.0.2b7 are both buggy implementations. Neither one is faithful to the syntax description. I agree. There is one markdown -- the syntax rules. While there may be many implementations, they are all buggy -- whether intentional or not. Actually, I might be persuaded that there there is two: the rules, and extended markdown -- which would be all intentional deviations from the rules. If your documents are markdown then they strictly follow the rules and mostly likely will be parsed by all markdown parsers the same way. However, if your document is extended markdown, then all bets are off. Such a label is in effect saying; Hey, this text document represents markdown text, but may not strictly be pure markdown text. Weird things may happen. Consider yourself warned. Beyond that, I see no need to specify anything further. Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: text/markdown effort in IETF (invite)
On Jul 09, 2014, at 11:49 AM, Sean Leonard dev+i...@seantek.com wrote: Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00 . My response below is lengthy but covers a number of different points including some raised later in the discussion by others. Sean, have you reached out to Mr. Gruber specifically? I mention this because in the past I have CCed him directly on a response I sent to this list which prompted him to respond (admittedly that happened some years ago). I suspect he might be amenable to the general idea though. A search of the list archives turned up a previous discussion [1] where he indicated a willingness to put in some work to obtain a mime type for markdown. Of course, that was back when he was still actively involved. Your mileage may vary. [1]: http://article.gmane.org/gmane.text.markdown.general/1179 In any event, I have some thoughts about your proposal. I like it for the most part. But a few comments on some specifics: Why do we need a Mime Type? First of all, when is this necessary? In order words, when is plain markdown being sent around such that it needs a mime type? In my experience, REST API's (for example) use JSON or XML which may contain some Markdown text among other data. That other data may identify that the text is markdown, but the mime type for the file is JSON or XML (or at least the appropriate mime type for that file type). Or are you proposing that everyone standardize on a way to identify the markdown text within JSON and XML documents as Markdown text? What am I missing here? Encodings -- To shed a different light on the encoding issue, consider Python-Markdown (disclosure: I'm the primary developer). Just as in Python 3 (where all strings are Unicode), Python-Markdown only works with Unicode. You pass Unicode text in, and you get Unicode text out. It is up to the user of the library to concern themselves with encoding and decoding a file to/from a specific encoding. As Python provides the libraries to do that, it is not a big problem -- although for those used to working with byte strings it may be a little jarring (I'm seeing that reaction from people who are experimenting with Apple's new Swift Language -- which also supports Unicode only strings). The point is, the Python-Markdown implementation has no use for the encoding (except for the included wrapping commandline script). Of course, the user (user of the library) will care about that and will need some way to identify the encoding before converting and passing the input on to the Python-Markdown library. So yes, encoding is very much a real, needed piece of meta-data. However, if the markdown text is included in a JSON file (see my previous point above), then wouldn't the encoding be defined for the JSON file, not the markdown text specifically. The JSON parsing library would just spit out a Unicode string -- in which case, why do we need this? Flavors - To me, flavors seems like a disaster waiting to happen. Sean, I realize you have specifically stated a lack of understanding here, so lets go back in time. The following may not be an all-inclusive (or in proper order of events) history of Markdown, but provides enough (I hope) to make a point. Way back when, the flavor of markdown you used depended almost entirely on which language (Perl, PHP, Python...) you were using to code your project (blog, wiki, CMS, etc.). If you where using PHP, them your flavor was PHP Markdown... There was only one implementation per language and they (mostly?) agreed with each other. In that day flavor was completely pointless. I suspect a number of us resistant to the flavors part of your proposal are from that period in Markdown's history. Of course, then Ruby came along. I don't remember which library was which, but when the first library came out, it was not very good (lots of bugs and slow). Then a second library came out which also wasn't very good, but in different ways (except for the slow part). Some people wrote their markdown documents with the bugs of the first implementation in mind, while other's wrote their documents with the second in mind. Then a few projects started offering users the option to pick which Ruby implementation of Markdown to use for each individual document - and flavors were born. Then other people started making ports of those projects to other languages and the flavors followed -- even though the other languages didn't really have any choices. As a reminder, Github came out of that Ruby culture, which might explain why Github-Flavored-Markdown ever existed in the first place (interesting side note: Gruber appears
RE: text/markdown effort in IETF (invite)
I think this comment [1] by Gruber on the mailing list in the past can shed some light on what the spec is (is it markdown.pl, the syntax rules on daringfireball.net, some mashup of various implementations, or something else?). According to Gruber, it is the syntax rules and that's it. If that is not good enough to get a mime-type, then I dont think there is anything else we can do. [1]: http://six.pairlist.net/pipermail/markdown-discuss/2008-February/001001.html -Original Message- From: Markdown-Discuss [mailto:markdown-discuss-boun...@six.pairlist.net] On Behalf Of Sean Leonard Sent: Wednesday, July 09, 2014 4:00 PM To: markdown-discuss@six.pairlist.net Subject: Re: text/markdown effort in IETF (invite) On 7/9/2014 12:06 PM, Michel Fortin wrote: Le 9-juil.-2014 à 11:49, Sean Leonard dev+i...@seantek.com a écrit : Hi markdown-discuss Folks: I am working on a Markdown effort in the Internet Engineering Task Force, to standardize on text/markdown as the Internet media type for all variations of Markdown content. You can read my draft here: http://tools.ietf.org/html/draft-seantek-text-markdown-media-type-00. The proposal is already getting traction. Is there anyone on this list that is interested in participating or helping this effort? In particular we need to better understand and document what versions of Markdown exist, so that either Markdown as a family of informal syntaxes will start to converge, or if not, that Markdown variations have an easy way to be distinguished from one another. (See the flavor parameter discussed in the draft.) The flavor parameter is a good idea in theory. I'm not sure it'll be very useful in general though. Nobody is going to annotate their file with the right flavor unless there's a tangible benefit, and I don't see what the benefit could be. Software that could do something useful with markdown-identified content will likely ignore the flavor part when parsing because no one wants to see incompatible flavor errors, especially when commonly used parts of the syntax are compatible anyway. Markdown is in the spot where HTML was before HTML5 with each implementation doing its own thing. I don't know if Markdown will get out of there anytime soon. I'll point out however that HTML never got anything like a flavor parameter in its MIME type, and even if it did it'd not have helped clear the mess in any way. Ok so here is where I really want to focus and learn some stuff from the Markdown community. I am a fairly heavy Markdown user, but not a Markdown developer or maintainer [yet]. From what I have gathered of Markdown history as an observer, getting this into one standardized syntax is like herding cats. Someone complains about how _ and * interact, or how to do tables such-and-such a way, and then they go off and write a different tool that does it differently. Ultimately it's as much about style (which is very personal) as functionality. To make matters worse, Gruber isn't providing leadership, so anyone can write Son of Markdown and before you know it we'll have 50 different standards. http://xkcd.com/927/ If someone else manages to write a formal specification, I am happy to refer to that normatively in the (proposed) IETF work. If the community manages to coalesce around that spec, I am also happy to refer to that spec as the exclusive normative reference. But...you may as well boil the ocean. So I'm not going to attempt that. I just want to call the ocean for what it is, and it's not text/plain. :) Sean ___ 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: Links in Code Blocks
Considering that one of the features of Code Blocks is that they can be used to display markdown syntax in its original source, the answer would be no. There is no way to have markdown syntax interpreted inside a code block. This would be one of those things that you would need to do with raw HTML as others have already demonstrated. Waylan On Wednesday, March 26, 2014, Tom Maynard t...@maynard.com wrote: Is it possible to have a live hyperlink *inside* a \`\`\`Code Block\`\`\`? Something like: ```markdown This code block contains an embedded [hyperlink](http://en. wikipedia.org/wiki/Hyperlink). Is it possible to render it as an active link instead of source? ``` I realize that Markdown support already exists, but it doesn't work. And, I also realize that what I'm asking for is diametrically opposed to what a Code Block is meant to be (even one with syntax highlighting. It's a WYSIWYG functionality, and I'm trying to circumvent it (at least partially). Is there a way? ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: RFC: Remove p Paragraph Tags between li Tags
On Saturday, November 23, 2013, Mariusz Wojcik wrote: li[Home](/)/li li[About Me](/about-me.html)/li li[Projects](/projects.html)/li creates plia href=/Home/a/li lia href=/about-me.htmlAbout Me/a/li lia href=/projects.htmlProjects/a/li/p Is this a bug or a feature? I think it shouldn't be that way because the p Tags around `li`s are illegal. As the docs [1] state: “Markdown is smart enough not to add extra (unwanted) `p` tags around HTML block-level tags.” The key there is “block-level tags” which `li`s are not ( go ahead and check the HTML spec on that). If you want to create raw HTML lists, then you need to wrap them in the appropriate block-level tag yourself. This is a case of garbage in - garbage out. When you're using raw HTML, you need to use valid HTML. Markdown will not fix your invalid HTML for you. So, in your case, a `li` not in a `ol` or `ul` in not valid HTML. Therefore markdown doesn't fix it to make it valid. Markdown's understanding of HTML is way to limited for that. Hope that explains things for you. [1]: http://daringfireball.net/projects/markdown/syntax#html -- Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Media block
There is a third-party extension to python-markdown for embedding youtube videos in a document. You might find it interesting: https://code.google.com/p/python-markdown-video/ \X/ /-\ `/ |_ /-\ |\| Waylan Limberg On Thu, Nov 14, 2013 at 1:06 PM, Johannes Wärn warn.johan...@gmail.com wrote: I will start of with an example of what I would like to be able to write in Markdown. --- This is a dummy paragraph, it would of course be longer than this. This is just another dummy paragraph; however, after it comes some pictures of my cat. http://www.example.com/pictureofmycat1.jpg http://www.example.com/pictureofmycat2.jpg http://www.example.com/animatedpictureofmycat.gif That was nice. Here is an audio recording of my dog barking: http://www.example.com/dogbark.mp3 And finally here is a video of my two pets being cuddly: http://www.example.com/dogandcat.mp4 --- I think it’s clear that the output I am suggesting for this would be something along these lines: pThis is a dummy paragraph, it would of course be longer than this./p pThis is just another dummy paragraph; however, after it comes some pictures of my cat./p divimg src=http://www.example.com/pictureofmycat1.jpg//div divimg src=http://www.example.com/pictureofmycat2.jpg//div divimg src=http://www.example.com/animatedpictureofmycat.gif//div pThat was nice. Here is an audio recording of my dog barking:/p audio src=http://www.example.com/dogbark.mp3;/audio pAnd finally here is a video of my two pets being cuddly:/p video src=http://www.example.com/dogandcat.mp4;/video I’d also say that the advantage of the syntax is clear: it’s dead simple. Furthermore it downgrades quite nicely. There are of course problems it does not solve and extra complexity it would introduce; however, I thought I’d write this short email to see if anyone would be interested in discussing the idea. Thank you for reading, Johannes Wärn ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: attribute blocks for definition lists
On Mon, Jul 1, 2013 at 11:33 AM, Matthieu Codron
codronm+markd...@gmail.com wrote:
the syntax would be
term {#id}
: definition
Python-Markdown already has extensions for Attribute Lists [1] and
Definition Lists [2] (both also available as part of Extra [3]).
However, due to the restriction that definition list terms can only be
on a single line (each line is a separate term), it was impossible to
assign attrs to the term. I was already special casing headers (h1-6)
for the same reason, so it wasn't too hard to adapt the code to work
with dt's also.
I just pushed a fix [4] which implements support for this syntax (you
can set any kind of attribute supported by the attr_list extension)
and it should be available in the next release of Python-Markdown
(probably 2.3.2). As always, testing/feedback is welcome.
[1]: http://pythonhosted.org/Markdown/extensions/attr_list.html
[2]: http://pythonhosted.org/Markdown/extensions/definition_lists.html
[3]:http://pythonhosted.org/Markdown/extensions/extra.html
[4]:https://github.com/waylan/Python-Markdown/commit/a9ca97325e9039de90eae29fb3d8879bc9f367f6
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Mysterious MD5ification under very specific circumstances
Wolfgang, Which implementation of the markdown parser are you using? Perl, php, ruby, python, javascript, ... (and many more) and which version specificly? Ask to an explaination, some implementations of the parser use MD5 Hashes as placeholders for the already parsed pieces of the document. My guess is that you found an edge case which tripps up the code that swaps out the placeholders for the parsed html. Waylan Limberg way...@gmail.com On Jun 28, 2013 11:55 AM, Wolfgang Faust wolfgang...@gmail.com wrote: I was building a markdown document today when my document suddenly went blank. When I looked at the HTML source, I found that all my codeblocks had been MD5ified. The following is a minimal document which reproduces the error: # Header # !-- There can be text here, but there doesn't have to be. -- This is a codeblock. **Bold text** !-- Another comment -- In particular, there must be: - A header - A comment containing the sequence NEWLINE TAB followed by at least two greater-than signs - At least one codeblock - Bold text - Another comment at the end of the document. Changing even the smallest detail in the markdown results in a correct HTML document, as expected. When I run this through markdown v.1.0.1, I get: h1Header/h1 !-- 702c6078df02d6d43aa6003f415a0408 /blockquote 46815d21b36c42e3ef8dcf757dd5758a **Bold text** !-- Another comment -- What on earth is going on here, and who do I report this bug to? ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Styling Markdown approaches
I think the syntax rules regarding raw html [1] shed some light on this issue: Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text. For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags. In other words, if you want a *publishing* format, use raw HTML. If you want to wrap some text in a div to add styling hooks, fine. But if you want to format the contents of that div, then use HTML for that also. After all, Markdown is not a replacement for HTML. Yes, some markdown implementations have added some optional extras, but those extras generally fit into the philosophy quoted above (see definition lists). That said, I have seen some pretty horrid requests for extending the syntax as the maintainer of the Python-Markdown project (which has an extensive API for writing extensions). While I agree that user defined extensions are an appropriate way to go, one should always be careful when introducing new syntax. John MacFarlane's FAQ [2] is evidence of that. [1]: http://daringfireball.net/projects/markdown/syntax#html [2]: http://johnmacfarlane.net/babelmark2/faq.html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Admonitions! with Python-Markdown 2.3 release.
Last night I released version 2.3 of Python Markdown (see the release notes [1] for all the details). In addition to various other improvements, a new **experimental** extension was included that added a syntax for generating rST-style admonitions [2]. For a summary of the syntax, see the documentation [3]. A broader sample of the output can be seen on this page [4]. The source text can be found by swapping the .html file extension for .txt [5]. You can test it here [6] (be sure to enable the extension). !!! Warning Experimental code has been released into the wild! As noted, this is considered experimental. It is subject to change. I realize that I could have overlooked something obvious and am not yet completely committed to the syntax. Interestingly, I had drafted a proposal some time ago (maybe a year ago) but never finished it. Independently, slig [7] proposed an almost identical proposal [8]. Seeing how close our proposals were, we tweaked the syntax (meeting in the middle) and slig wrote all the code. So what does everyone think? I know the examples in the Python-Markdown docs aren't the best. We're using the Python default documentation theme (CSS) which makes the title inline with the first paragraph - which is a little weird. What's great about it though, is that no changes needed to be made to the CSS for it to work. Same applies to any Sphinx themes [9]. [1]: http://pythonhosted.org/Markdown/release-2.3.html [2]: http://docutils.sourceforge.net/docs/ref/rst/directives.html#specific-admonitions [3]: http://pythonhosted.org/Markdown/extensions/admonition.html [4]: http://pythonhosted.org/Markdown/reference.html [5]: http://pythonhosted.org/Markdown/reference.txt [6]: http://waylan.pythonanywhere.com/dingus [7]: https://github.com/slig [8]: https://github.com/waylan/Python-Markdown/issues/133 [9]: http://sphinx-doc.org/theming.html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: footer and cie.
On Fri, Feb 8, 2013 at 4:38 PM, Michel Fortin michel.for...@michelf.ca wrote: In PHP Markdown 1.0.1p I started treating them as block-level elements and they get the same treatment as `div`, but implementations don't seem to agree on this I see three different outputs (babelmark2 shows more, but treatment of whitespace and/or the encoding the apostrophe in don't are throwing things off). 1) `footer` and its contents are untouched. 2) `footer` is left alone but its contents are processed as inline markdown. 3) The whole thing is wrapped in a `p` and contents are processed as inline markdown. The reason for #3 is easy. Those parsers don't know anything about the `footer` tag - which we all know is new in HTML5. Most likely, they (like markdown.pl) have a hardcoded list of block level tags and anything else in raw html is assumed to be span level tags. As I see it, these can simply be ignored as being outdated/not supporting HTML5. My suggestions would be to say that if you want to use HTML5 don't use these implementations. Yes, that means HTML5 support is a feature, just like footnote support is a feature. Uhg. I think it is safe to say that the reason for #1 is that the devs have added the footer tag to the list of hardcoded block level tags - which means it gets missed by span level parsing. These implementations can say they support HTML5, but the lack-of-span-level-parsing feels limiting. I'm guessing that implementations of #2 work as they do because a conscious decision was made to allow span level parsing. But what do these implementations do for divs? I just checked and they also do span level parsing inside `div` and `p` tags, etc. http://johnmacfarlane.net/babelmark2/?normalize=1text=%3Cp%3E%E2%80%94+%5BIgor+Wiedler+wins%5D(https%3A%2F%2Figor.io+)%3C%2Fp%3E%0A%0A%3Cdiv%3E%E2%80%94+%5BIgor+Wiedler+wins%5D(https%3A%2F%2Figor.io+)%3C%2Fdiv%3E%0A%0A%3Cfooter%3E%E2%80%94+%5BIgor+Wiedler+wins%5D(https%3A%2F%2Figor.io+)%3C%2Ffooter%3E So, if you want to follow the no-span-level-parsing-in-block-level-html rule, your left with choosing #1 or #3 (the former being with HTML5 support). However, if you want to ignore that rule, then #2 seems to be the way to go. Personally, I've never liked that rule (no-span-level-parsing-in-block-level-html), but it is a clearly defined rule and should be the default behavior. I went with #1. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Community Group for Markdown Standardization
it was too time-consuming. http://michelf.ca/specs/markdown-extra/ Pretty much at the same time, I made Babelmark for comparing various Markdown implementations. Ian Hickson wrote a similar tool to see how browsers were parsing HTML snippets to help build the parsing spec for HTML. I figured it'd help to have something similar for Markdown. http://babelmark.bobtfish.net John MacFarlane rewrote it as Babelmark 2 a few months ago, with more up-to-date versions of the implementations. It's really great. http://johnmacfarlane.net/babelmark2/?text=aasdf - - - If I had to fix Markdown today, I'd radically change to a cheap approach. I'd take the few worse cases from the Babelmark 2 FAQ, try to come up with a right way to parse these, put them in a test suite and try to convince other implementations conform to that test suite. Even that would probably be a hard sell to me, and probably others. I'm pretty picky about what's right and wrong in Markdown. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: horizontal space/indent and HTML/PDF
On Tue, Oct 30, 2012 at 11:57 AM, Chris Lott ch...@chrislott.org wrote: What is the best method to introduce horizontal space in text in a Pandoc document? Preferably something that would work for both HTML and PDF output? Well, there are a few different things you could try: The easiest would be to put the entire poem in a code block. Of course, that may not be as pretty (with a monospaced font) and you lose inline markdown (emphasis, links, etc). http://johnmacfarlane.net/babelmark2/?normalize=1text=hickory+dickory+dock%0Athe+mouse+ran+up+the+clock%0A+the+clock+struck+one%0Athe+mouse+ran+down A second option would be to use html entities for non-braking spaces (`nbsp;`). You only need to make every other space non-breaking. And don't forget to end each line with two spaces to force the line breaks. Like this: hickory dickory dock nbsp; nbsp; nbsp; the mouse ran up the clock nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; the clock struck one the mouse ran down http://johnmacfarlane.net/babelmark2/?normalize=1text=hickory+dickory+dock++%0A+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+the+mouse+ran+up+the+clock++%0A+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+%26nbsp%3B+the+clock+struck+one++%0Athe+mouse+ran+down Of course, that doesn't look so nice in markdown, but works great in HTML. The HTML spec actually suggests that poetry could be wrapped in a `pre` tag (but without the inner `code` tags of the code block). So, you could use raw html like this: pre hickory dickory dock the mouse ran up the clock the clock struck one the mouse ran down /pre http://johnmacfarlane.net/babelmark2/?normalize=1text=%3Cpre%3E%0Ahickory+dickory+dock%0Athe+mouse+ran+up+the+clock%0A+the+clock+struck+one%0Athe+mouse+ran+down%0A%3C%2Fpre%3E I'm not sure if Pandoc will parse inline markdown in there or not (some parers might if you set markdown=1 on the pre tag). And I'm not sure how any of the above will translate to PDF. But that should get you started. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: How to insert a blank line between blockquote paragraphs?
On Wed, Oct 24, 2012 at 4:18 PM, Waylan Limberg way...@gmail.com wrote: On Wed, Oct 24, 2012 at 4:09 PM, Thomas Maibaum thomasmaib...@gmail.com wrote: Hello everyone, First off, I'm new to this list, so if this has been dealt with before, I apologize. I was unable to find a solution in Google. My question is, how do I insert a blank line between blockquote paragraphs so that they are visually separate? I often need to put two or three separate blockquotes in a row, without any regular text between them, but Markdown always renders the HTML output like one long quote. Like this: Well, if you don't want the output to be visible, and as Markdown accepts raw html, why not an html comment. Like this: http://johnmacfarlane.net/babelmark2/?normalize=1text=%3E+foo%0A%0A%3C!--+blank+line+--%3E%0A%0A%3E+bar%0A%0A%3C!--+blank+line+--%3E%0A%0A%3E+baz You can even eliminate some of the blank lines like this: http://johnmacfarlane.net/babelmark2/?normalize=1text=%3E+foo%0A%0A%3C!--+blank+line+--%3E%0A%3E+bar%0A%0A%3C!--+blank+line+--%3E%0A%3E+baz Although that breaks pandoc in strange ways. However, all other implementations handle that fine and you save a few blank lines in your document. The rest are necessary though. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Trouble with parentheses in Markdown hyperlinks
On Wed, Oct 24, 2012 at 11:18 PM, David Chambers david.chambers...@gmail.com wrote: On Wednesday, October 24, 2012 at 7:25 PM, John MacFarlane wrote: Github has wikis for each project. Example: https://github.com/jgm/pandoc/wiki You'd only have to create a 'markdown' project, which needn't have anything in it but a README.markdown file with a link to the wiki. Anyone with a github account could edit the wiki. This seems far easier than any of the other proposals. I created the markdown account on GitHub some time ago. If there's support for John's suggestion, we could create a public repository in that account and use its wiki. +1 from me. There used to be an old wiki (I forget where) which lasted for some years. But it died a slow death. First from lack of maintenance, then from spam, then from being locked down to avoid the spam. No longer being publicly editable was the last nail in its coffin. At least that's the way I remember it. The thing about github it that is has user management features to help with spam, etc. (not that other wiki systems don't but...) David if you make that user account an organization then if/when you ever lose interest in or run out of time to maintain it, you can share with or pass ownership off to any other github user - with no need to pass off control of a hosting account or move it to a new hosting account or transfer control of a domain ... and all the other relevant headaches with that sort of thing. Also, as a bonus, the default page url (using github pages) would be markdown.github.com - which is even better that github-flavored-markdown gets. Sure, that page wouldn't be as easily editable as a wiki, but just make it static with general info and a link to the wiki - or don't - use pull requests as moderated editing of the github page. Trusted and frequent editors of the doc (and/or implementation authors) could be given full editing privileges of the underlying repo using there respective user accounts (which privileges could still be revoked upon abuse). For that matter, as an organization, each implementation author could host their implementation under markdown/[implementation_name]. Or if they don't want to, auto-updating mirrors could be added (although, unfortunately, the auto-updating script would need to be maintained externally). Great for one-stop shopping for all implementations. I know I'd use it to browse markdown.pl's source - rather than downloading the zip file. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: How to insert a blank line between blockquote paragraphs?
On Wed, Oct 24, 2012 at 11:33 PM, David Chambers david.chambers...@gmail.com wrote: http://johnmacfarlane.net/babelmark2/?normalize=1text=%3E+foo%0A%0A%3E+bar%0A%0A I love pandoc's approach here. It's logical, and makes it just as trivial to mark up consecutive single-paragraph quotes as it is to mark up a two-paragraph quote. This is exactly the sort of thing that could be profitably discussed were we not bound by the somewhat inconsistent behaviour of the original Perl script. Do others agree that pandoc's treatment of such cases is preferable to the “specified” behaviour? What I'm asking is what others would advocate if we were discussing a hypothetical format with no backwards-compatibility concerns. (Let's not have every discussion derailed by the backwards-compatibility discussion.) :) I already stated my opinion in a separate message on what is proper behavior in markdown, but your not asking about that here. Sure, if I was involved in designing some new inspired-by-markdown-but-not-markdown language, then yes Pandoc's behavior would get my vote in this instance. The thing is, I'm not really interested in designing by committee, and I don't follow this list to consider inspired-by-markdown languages. I follow this list because I maintain a _markdown_ implementation and sometimes support questions for my implementation get asked here - or sometimes inconsistencies in implementation can be worked out - or something like babelmark2 comes along which I want to know about, use, and provide access to my implementation for... (you get the idea). Most anything else is just an annoying distraction to me. Sure, if people want to announce some new markdown related project here - great, I'm glad to see markdown grow. But I'm not interested in filtering through message after message about some hypothetical inspired-by-markdown language that know one is putting any real work into (and if there is real work - great - but that discussion belongs elsewhere). But hey, I'm just one person. What do I know? Maybe my overly busy schedule lately is making me ornery. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Multidingus
Very interesting examples in that FAQ.
Although I would say this one is a little misleading:
http://johnmacfarlane.net/babelmark2/?text=%5C%5C%5Btest%5D(not+a+link%3F)http://johnmacfarlane.net/babelmark2/?text=%5C%5C%5Btest%5D(not+a+link%3F)%0A
It would more accurately be this:
http://johnmacfarlane.net/babelmark2/?text=%5C%5C%5Btest%5D(notalink%3F)http://johnmacfarlane.net/babelmark2/?text=%5C%5C%5Btest%5D(notalink%3F)%0A
While that is a lot less interesting, it is not exhibiting the issue of
spaces in urls - which is the next item on your list.
There could also be this:
http://johnmacfarlane.net/babelmark2/?text=%5C%5Btest%5D(notalink%3F)
Which is also not very interesting. The only difference in these two
examples is the way php markdown handles escaped characters - which has
nothing specific to do with links. Seems to me like none of
these examples belong on the list.
Waylan
On Sat, Oct 20, 2012 at 11:21 PM, John MacFarlane j...@berkeley.edu wrote:
Thanks! I've added a FAQ:
http://johnmacfarlane.net/babelmark2/faq.html
This contains a longer list of interesting examples of differences
between implementations, plus instructions on how to get your markdown
implementation added to the comparisons.
+++ David Chambers [Oct 19 12 15:16 ]:
This is a terrific tool, John. I now realize how much disagreement
there is between the different Markdown libs on certain topics (such
as
consecutive lists).
David
On Friday, 19 October 2012 at 2:51 PM, John MacFarlane wrote:
+++ Alan Hogan [Oct 19 12 14:07 ]:
Here’s a tiny bookmarklet that can be run on Babelmark 2 as it stands
today, that replaces all the pre elements on the page with an HTML
preview:
javascript:$('pre').each(function(i, el){ var html = $(el).text();
$(el).replaceWith($('div style=border: 1px solid #aaa;
border-radius:
4px /').html(html)); });
Or, you may drag it into your bookmarks page from here:
[1][1]http://peg.gd/2IU
It’s not Good Code and doesn’t do anything useful like add tabs to
switch between representations, but hey, I spent five minutes on this
and it’s kind of useful, so I’m sharing it.
Alan,
This is useful. I've incorporated it into the site itself, so you
can now toggle between Preview and Code modes. When I have a bit
of time I'll make it use tabs for this instead -- that would be nicer.
John
___
Markdown-Discuss mailing list
[2]Markdown-Discuss@six.pairlist.net
[3]http://six.pairlist.net/mailman/listinfo/markdown-discuss
References
1. http://peg.gd/2IU
2. mailto:Markdown-Discuss@six.pairlist.net
3. http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Trouble with parentheses in Markdown hyperlinks
On Thu, Oct 18, 2012 at 1:38 PM, Andrew Pennebaker andrew.penneba...@gmail.com wrote: Could we standardize URL-parsing regexes across Markdown implementations? Can we come up with a really super regex and invite the various fork developers and maintainers to use that regex? There are at least 3 possible problems with this: 1) This assumes that all implementations use regex. That may not necessarily be the case. For example, peg markdown is a peg parser. While I'm not sure if it uses a peg grammar or regex for matching urls (I didn't go check), why should it be required to use a regex? 2) Not all languages (perl, python, ruby, php, lua, ...) use the same regex implementation. For instance, when developing the python implementation of markdown, I have had to work around a few features of the perl regex implementation that do not exist in python. Had JG been working in a language other than perl when he first developed the markdown syntax, I suspect a few things would be different. Some subtle features of the syntax are definitely a direct result of how perl's regex works. Nothing that can't be overcome - but not always with regex (see [this][] example). [this]: https://github.com/waylan/Python-Markdown/commit/ef9a229ebeaf8173e9fd4e541de4d83e8678f649 3) Even if the above issues didn't exist, how would you be able to convince all of the implementors to use it in their implementations? Oh, and to address the original issue starting this thread, along with the others mentioned, Python-Markdown also parses the url with parenthesis correctly. I would suggest filing a bug report with whichever implementation Stack Overflow uses and hope that that implementation is still under active development. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: pre in lists
On Fri, Aug 17, 2012 at 3:57 AM, Boris Le Ninivin boris.lenini...@gmail.com wrote: [snip] Thank you for your suggestion. However, I use ikiwiki, and, if I do so, it's to avoid using php, ruby or anything else ;) So, I'll rather patch ikiwiki than install a hanful of packages to solve a simple problem ;) Well, as far as I can tell, ikiwiki is written in Perl. Not sure which perl implementation it uses (there are 3 IIRC), but I believe all of them implement nested code blocks properly. Perhaps you are providing bad input? What you should have is: ~ 1. some text 2. some code : My first line of code The second one Some indented code Another line 3. end of the list ~ Note the blank line before the block and at least 8 spaces of indent. That is the only way to nest a standard markdown style code block inside a list. Remember, without the blank line, you just add more inline text to the list item and with only 4 spaces of indent you only get a paragraph inside a list: 1. First line of first paragraph in list item. Second line of first paragraph in list item (indented 4 spaces). Second paragraph of first list item (indented 4 spaces). Second line of second paragraph (indented 4 spaces). A code block nested in list item (indented 8 spaces). Another paragraph nested in list item (indented 8 spaces). 2. A new list item. Hope that helps. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Footnote output not valid.
On Tue, Aug 7, 2012 at 10:30 PM, Michel Fortin michel.for...@michelf.ca wrote: Le 2012-08-07 à 15:43, Waylan Limberg way...@gmail.com a écrit : Of course, following markdown.pl's lead, the default is XHTML, so yeah, most will never get HTML5 output. Although, I suppose we could easily have our footnote extension not add the `rel` and `rev` attributes to footnotes when HTML5 is selected. Well, I'm not so sure rel=footnote is actually almost valid. The HTML specs gives a few normalized values, then says that other values must be registered on this microformat.org page: http://microformats.org/wiki/existing-rel-values rel=footnote is there on that page, in the POSH usage section, citing Markdown preprocessors as the source. But it's missing a spec. Someone would have to go through the microformat process and create a spec for it and it'll become valid. True, but it is also listed in the dropped section. If one it proposing a spec for anything that has previously been dropped, there is a larger hurdle to jump. For example, the proposal needs to explore why it was previously dropped and why that reason does not apply to the current proposal. And if I understand it correctly, certain reasons (for previously being dropped) will cause all future proposals to be rejected automatically, while other reasons may be open to reconsideration. Unfortunately, whoever added footnote to the dropped list left the reason as unknown. So it looks like it might be a lot of work to submit an acceptable proposal. Rev is definitely deprecated however. I don't think it'll come back. If someone defines a spec for rel=footnote, it could also define what is the opposite of rel=footnote and replace the rev=footnote with something else such as rel=footnote-ref. Then the path forward might be to include both rev=footnote rel=footnote-ref, unless someone has specified a flag to prevent the rev attribute from showing up. But until that happens, our markdown implementations are outputting invalid html. And according to the page linked above, they should not be used at all meaning we should be removing any occurrences of rel=footnote from our markdown implementations until such a proposal is approved. Of course, that only applies when outputting HTML5. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Footnote output not valid.
FYI, I found an examples page in the microformats wiki: http://microformats.org/wiki/footnotes-examples Because of the inclusion of the 's' in the url, I didn't find it right away. In any event, it documents various existing examples of footnote implementations (including Gruber's). Interestingly none of them use rel attributes (or rev for that matter). Maybe we should just drop that usage altogether in markdown. On Wed, Aug 8, 2012 at 3:35 PM, Waylan Limberg way...@gmail.com wrote: On Tue, Aug 7, 2012 at 10:30 PM, Michel Fortin michel.for...@michelf.ca wrote: Le 2012-08-07 à 15:43, Waylan Limberg way...@gmail.com a écrit : Of course, following markdown.pl's lead, the default is XHTML, so yeah, most will never get HTML5 output. Although, I suppose we could easily have our footnote extension not add the `rel` and `rev` attributes to footnotes when HTML5 is selected. Well, I'm not so sure rel=footnote is actually almost valid. The HTML specs gives a few normalized values, then says that other values must be registered on this microformat.org page: http://microformats.org/wiki/existing-rel-values rel=footnote is there on that page, in the POSH usage section, citing Markdown preprocessors as the source. But it's missing a spec. Someone would have to go through the microformat process and create a spec for it and it'll become valid. True, but it is also listed in the dropped section. If one it proposing a spec for anything that has previously been dropped, there is a larger hurdle to jump. For example, the proposal needs to explore why it was previously dropped and why that reason does not apply to the current proposal. And if I understand it correctly, certain reasons (for previously being dropped) will cause all future proposals to be rejected automatically, while other reasons may be open to reconsideration. Unfortunately, whoever added footnote to the dropped list left the reason as unknown. So it looks like it might be a lot of work to submit an acceptable proposal. Rev is definitely deprecated however. I don't think it'll come back. If someone defines a spec for rel=footnote, it could also define what is the opposite of rel=footnote and replace the rev=footnote with something else such as rel=footnote-ref. Then the path forward might be to include both rev=footnote rel=footnote-ref, unless someone has specified a flag to prevent the rev attribute from showing up. But until that happens, our markdown implementations are outputting invalid html. And according to the page linked above, they should not be used at all meaning we should be removing any occurrences of rel=footnote from our markdown implementations until such a proposal is approved. Of course, that only applies when outputting HTML5. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Footnote output not valid.
On Tue, Aug 7, 2012 at 2:06 PM, Michel Fortin michel.for...@michelf.ca wrote: Le 2012-08-06 à 21:07, Waylan Limberg way...@gmail.com a écrit : I just received a report [1] that the footnote output we use in Python-Markdown (an exact copy of PHP Markdown Extra [3]) is not valid HTML [3]. If you notice he's using HTML5. At least the footnote syntax does valid on XHTML1 or HTML4. Anyway, any suggestions on how the various footnote implementations want to move forward with this? [1]: https://github.com/waylan/Python-Markdown/issues/129 [2]: http://michelf.ca/projects/php-markdown/extra/#fn-output [3]: http://validator.w3.org/check?uri=http%3A%2F%2Fblog.posativ.org%2F2012%2Flinkschleuder-26%2Fcharset=%28detect+automatically%29doctype=Inlinegroup=0 Another link you might want to check out: https://github.com/michelf/php-markdown/wiki/HTML5-update I'm not actually sure what to do about this. One idea is to have a master switch making all output HTML5-conformant. The real problem is that some people might be relying on the current markup, stylesheets at least. So that switch should be disabled by default, which would ensure almost no one gets HTML5 markup. Interestingly, in Python-Markdown we have an output-format [1] switch which can be set to various versions of HTML and/or XHTML. Although, all HTML versions get the same output and all XHTML versions get the same output. The only difference (right now) between HTML and XHTML are things like `hr` verses `hr /`. Of course, following markdown.pl's lead, the default is XHTML, so yeah, most will never get HTML5 output. Although, I suppose we could easily have our footnote extension not add the `rel` and `rev` attributes to footnotes when HTML5 is selected. Seems silly though - to have a less semantic document because an unfinished standard has depreciated a commonly used syntax, especially when no browser will trip on it - just for the sake of having a document validated by an experimental validator. [1]: http://packages.python.org/Markdown/reference.html#output_format -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Definition list as image caption
On Fri, Jun 22, 2012 at 7:00 AM, Jakob ja...@gmx.at wrote: recently though about image captions, then i realized that this could be achiebed by Markdown Extra's definition list feature:  : here goes the *caption* What do you think? Hmm, what HTML are you suggesting that output? Standard Definition List HTML? How would that translate to a caption? -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Definition list as image caption
On Fri, Jun 22, 2012 at 12:04 PM, Jakob ja...@gmx.at wrote:
Von: Waylan Limberg way...@gmail.com
Hmm, what HTML are you suggesting that output? Standard Definition
List HTML? How would that translate to a caption?
In the meantime I rethought my proposal, but for the sake of being backwards
compatible with HTML4: I think it should take a figure class (only when it
is only images and that definition line), like this:
```
dl class=figure
dtimg alt=alt text src=http://example.com/img.jpg;/dt
dd class=figcaptionthe caption/dd
/dl
```
So you want the parser to special case dt's that contain an image and
then attach a bunch of classes to the output. That seems like it might
surprise the user a little too much and I don;t recall any other
syntax which follows a similar pattern. I don't like it.
like this i would be very similar to the HTML5 stuff (and could be easily
handled in CSS with `.figure {}` in HTML4 or just `figure {}` in HTML5):
```
figure
img alt=alt text src=http://example.com/img.jpg;
figcaptionthe caption/figcaption
/figure
```
I think this one probably falls in the should be in raw HTML camp.
Remember the syntax rules state that markdown is only for a subset of
HTML. These special cased HTML5 tags all strike me as raw HTML
material.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Definition list as image caption
On Fri, Jun 22, 2012 at 12:05 PM, Thomas Humiston t...@jumpingrock.net wrote:
It's a good idea, Jakob. Despite the name of this HTML element (which HTML5
moves to rename as description list), it exists for exactly the sort of
purpose you suggest -- or, as I like to say, DT is some object, DD is
something *about* that object.
No matter which implementation of Markdown (or anything else) one uses to
wrap content in HTML, the question is, What HTML element is appropriate for
the job? The answer isn't always stark, and DL has long been undervalued,
misunderstood, and largely forgotten, but it is indeed the best choice in
this case.
And in situations where the text includes discrete bits, such as a
photograph's copyright info and the name of the photographer in addition to
the caption, we see that it indeed becomes list-like, so that the
appropriateness of using DL becomes even more apparent.
Here's an example of styling for a photo and caption info in a DL element.
(Note: I made up the copyright info. If Wikipedia even allows hotlinking to
their photos, I'd first look up the correct way of doing it before using this
on a real site.)
div#example {
max-width: 20em;
}
dt {
padding: 5px;
border: 1px solid gray;
margin-bottom: 5px;
}
dt img {
width: 100%;
height: auto;
}
dd {
margin-left: 0; /* removes the indent */
color: gray;
font-size: small;
}
dd.maker, dd.copyright {
font-style: italic;
font-size: x-small;
margin-top: 1em;
}
dd.maker {
float: left;
margin-right: 2em;
}
dd.copyright {
float: right;
}
div id=example
dl
dtimg
src=http://upload.wikimedia.org/wikipedia/commons/f/fd/Fuzzy_Freddy.jpg;
alt=Foxy Freddy, from Wikipedia
ddFox is a common name for many species of omnivorous mammals belonging to
the Canidae family.
dd class=makerPhoto by Rob Lee
dd class=copyrightcopy;2012 Wikimedia / GPL
/dl
/div
Now, this is a proposal I can get behind - sort of. Of course its
really a non-proposal because it is already possible with no
modification to at least some implementations. The only proposal here
is to determine what hooks the CSS should expect. And I've never seen
markdown require specific classes as styling hooks. But, hey, if you
want to standardize internally within your organization, that is a
good starting place.
The best part is, any implementation that already supports definition
lists, markdown processing inside raw html blocks and attribute lists
[1] [2] can generate that output. The input would look like this:
div class=example markdown=1
![Foxy Freddy, from Wikipedia]
(http://upload.wikimedia.org/wikipedia/commons/f/fd/Fuzzy_Freddy.jpg)
:Fox is a common name for many species of
omnivorous mammals belonging to the Canidae
family.
:Photo by Rob Lee
{: .maker }
:copy;2012 Wikimedia / GPL
{: .copyright }
/div
The key is that the wrapping div has a hook set (changed it to a
class, not an id - otherwise you could only have one
image-with-caption per page) identifying it as a image-with-caption.
Author a definition list without that div/class hook, and it is a
regular definition list. Either way, the markdown parser does the same
thing. Only the CSS cares and alters how it is displayed. Again, a
non-proposal as far as Markdown is concerned.
[1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
[2]: http://packages.python.org/Markdown/extensions/attr_list.html
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Paragraphs and html integration.
On Mon, Jun 18, 2012 at 7:31 PM, Boris Le Ninivin boris.lenini...@gmail.com wrote: On 06/18/2012 09:27 PM, Michel Fortin wrote: Le 2012-06-18 à 6:26, Boris Le Ninivin a écrit : In the end, on the df website, it is said that Markdown is smart enough not to add extra (unwanted) |p| tags around HTML block-level tags.. So I don't know if it's an implementation problem (related to the PHP port, maybe?), or if it's a design problem, but as far as I know, Markdown is not smart enough to not add unwanted p tags. That's only true for known HTML tags, and only the block-level ones. Does that mean that html and !doctype tags will be enclosed between p ? Yes. More specifically, known block-level tags that would only ever appear inside the body of a valid HTML4/XHTML1 document are recognized by Markdown. So any new tags introduced by HTML5 would also not be recognized - although some implementations may be starting to add them. Also remember that those tags must begin at the start of a line. No indentation allowed - or they not recognized as block level tags. Yes, this is documented - so most implementations follow it. If your adding html stuff to your documents, that is generally handled after markdown is run on the body. For example, most frameworks and template systems will use a template which generates all the stuff outside the body and perhaps a header/footer inside the body, and then use a template variable to insert the already converted markdown into the document. Markdown does not generally expect to have the already generated document run through it - although I know some people have had success using it that way in specific controlled environments. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Python-Markdown 2.1.1 Released
Python Markdown version 2.1.1 has been released. This is a bug fix release which fixes a few bugs which caused the parser to choke on certain edge cases. Everyone is encouraged to upgrade. http://pypi.python.org/pypi/Markdown/2.1.1 -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Inline HTML link and mailto: link
On Fri, Jan 13, 2012 at 1:15 PM, R (Chandra) Chandrasekhar chyav...@gmail.com wrote: Wow, that was a quick reply! Yes, indeed, I was putting a space between ] and (. I have corrected that and now both the links work as they should :-). May I ask a supplementary question please: How are em-dashes and en-dashes handled in Markdown? They aren't. You may want to check out [smartypants](http://daringfireball.net/projects/smartypants/) for that which was written by the same author. In fact, smartypants is a filter available on the Markdown Dingus (select markdown, smartypants or both). -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Python-Markdown 2.1.0 released.
Just letting everyone know that I just released Python-Markdown 2.1.0.final. Get from PyPi: http://pypi.python.org/pypi/Markdown/2.1.0 Read the release notes on github: https://github.com/waylan/Python-Markdown/blob/master/docs/release-2.1.0.md -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Multiline code block within a list
On Sun, Nov 6, 2011 at 10:11 PM, Ryan Chan ryanchan...@gmail.com wrote: Hello, How to correctly made multiline code block within a list, like.. * foo * bar * ``` Code 1 Code 2 Code 3 ``` * Another list item The above markup is not working, what I want is Code 1, Code 2 and Code 3 appear in different lines. Ryan, The backtick syntax is for code spans. If you want code blocks, then to should be using indented blocks. The block needs to be indented at least four spaces. Unfortunately, not all markdown implementations will recognize this (including markdown.pl). In fact, some implementations will will never allow *only* a code block in a list item. However, if you what to use the multiple block in a list item syntax that will work. Therefore, you list item will need some paragraph, followed by a blank line, followed by your code block. Of course, as additional blocks within a list item need to be indented four spaces, already, you will need to indent 8 spaces for a code block. So, something like this (spaces replaced by dots for illustrative purposes only): * foo * bar * A paragraph followed by a blank line Code 1 (8 spaces of indent) Code 2 Code 3 * Another list item If you don't want the extra paragraph, check http://babelmark.bobtfish.net/ for implementations that don't require it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: table spans
On Thu, Oct 6, 2011 at 2:06 PM, Fletcher T. Penney fletc...@fletcherpenney.net wrote: There is no table implementation in markdown. While Fletcher is technically correct, there are various implementations which do offer a table syntax. Unfortunately, not all of them offer the same syntax, so you'll need to specify which implementation you are using. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: input on stdin
Unfortunately, python-markdown did not always work on stdin (but did for stdout). This has since been rectified and will be available in the next release (2.1). Actually I though it was in the last release (2.0) but maybe not. On Sun, Aug 28, 2011 at 12:57 AM, Simon KP s...@eskp.net wrote: Well I was using python-markdown Arch Linux package and the command line tool markdown that comes with it. I have downloaded Markdown.pl which does work as a filter.. On Sun, Aug 28, 2011 at 2:10 PM, Simon KP s...@eskp.net wrote: Hi list, I have been trying to do something like this: cat first_post | markdown without any success. I think a text transformer should primarily serve as a UNIX filter not just a tool that opens files. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: edit in place - splitting a markdown text according to headers
On Wed, Aug 3, 2011 at 6:15 PM, Alexandre Leray newslett...@alexandreleray.com wrote: Hi, I'd like to implement an edit-in-place functionnality for a (python) markdown-based wiki. Does anyone know how I could proceed? I was thinking I could split the markdown file according to h1 headers... The rss extension [1] which ships with Python-Markdown sorta does this. Each section (split by h1) becomes an 'item' in an rss document. The extension is old and hasn't been maintained like the rest of the library and I don't really recommend it, but a look at the code may provide some guidance. However, the more I think about it, I'm not really sure how that would be translated to an edit-in-place feature. [1]: https://github.com/waylan/Python-Markdown/blob/master/markdown/extensions/rss.py -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
On Thu, Jul 14, 2011 at 12:47 PM, David Chambers
david.chambers...@gmail.com wrote:
Albert Skye mistl...@yahoo.co.uk wrote:
This paragraph has an attribute list attached by reference.
{ref}
[ref]: #id .class name=value
This strikes me as an elegant solution to the problem, askye. Does anyone
know of an extension that uses this syntax?
Maruku does (almost) [1] as a part of there attribute list syntax.
Basically, any single word (not a key=value pair or not starting with
a `#` or `.`) is treated as a reference. I have not implemented this
part in my implementation, mostly because I wasn't convinced that
Maruku's reference syntax was right.
[1]: http://maruku.rubyforge.org/proposal.html#using_tags
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: php-markdown-extra-extended - my humble attempt at extending php-markdown
Yes, I implemented an extension to Python-Markdown a few weeks back
which should be available in a release real soon now. Docs are here:
https://github.com/waylan/Python-Markdown/blob/master/docs/extensions/attr_list.txt
The other implementation is
http://kramdown.rubyforge.org/syntax.html#inline-attribute-lists
On Wed, Jul 13, 2011 at 2:53 PM, Alan Hogan cont...@alanhogan.com wrote:
Waylan, out of curiosity, which implementations are those? Is yours one?
Alan Hogan
http://blogic.com
cont...@alanhogan.com
On Wednesday, July 13, 2011 at 6:02 AM, Waylan Limberg wrote:
On Wed, Jul 13, 2011 at 4:12 AM, Egil Hansen e...@assimilated.dk wrote:
Dear all,
I have used Markdown via Drupal a few months now, with a customer site
and my currently my own blog and based on that practical experience I
wanted to add some extra functionality to PHP Markdown Extra, so out
of this grow my (extended) weekend project
https://github.com/egil/php-markdown-extra-extended
The big missing item right now that I would like to implement is the
ability to add classes to block and span elements. My basic idea is to
use a syntax like this: {some class}
If you're looking for prior art, I'd suggest Maruku's attribute lists
[1]. I'm aware of at least two other markdown implementations which
have adopted this.
[1]: http://maruku.rubyforge.org/proposal.html#attribute_lists
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
On Sun, Jun 5, 2011 at 8:35 PM, David Chambers david.chambers...@gmail.com wrote: Michel Fortin michel.for...@michelf.com wrote: I'd tend to go for something even simpler: Some text 30 May 2011 more text. *[30 May 2011]: 2011-05-30 15:00 -07:00 Basically, why do we need to force brackets in the text at all? Also, why force the writer to use 'T' as a time separator and strictly follow to the rules of HTML date syntax? It's much more readable without the 'T'. Reformatting it to HTML's liking should be pretty trivial. I love this idea. I'm unfamiliar with PHP Markdown Extra's abbreviation syntax (I'll read up on it); building upon an established convention sounds very sensible to me. I'll have to say I like this as well. It hadn't occurred to me that like the abbreviation syntax, we don't need to mark up the text at all. Regarding the time v. datetime, I picked datetime because that is the name of the html attribute the same value would be assigned to. But time is certainly shorter. Maybe you won't need either as Michel suggests. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: `time` element syntax
Interesting suggestion David. Although, you're right, I'm not sure
what real value this serves. Why can't we just use raw html here?
That said, there certainly is no reason why this couldn't be an
unofficial addon - in which case you would want to do it right. So
here are some thoughts on your suggested implementation:
On Thu, Jun 2, 2011 at 5:08 AM, David Chambers
david.chambers...@gmail.com wrote:
`/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d)(?::(\d\d)(?:[.](\d+))?)?([-+]\d\d:\d\d|Z)$/`
could be used to ensure that only valid `datetime` attribute values are
matched.
Ok, this looks like it would match a valid date and time [1], but what
about a date without time or a time without date [2]? According to the
spec, all three should be allowed [3]. Have fun building that regex.
:-)
This would avoid false positives and would keep `[foo]{bar}`
available for other functions, potentially.
I understand what you're trying to do here, but I suspect this could
conflict with the attribute list syntax used by a few
implementations.[4] I realize they start with a colon `{: ...}`, but
the similarity should at least be considered.
Another concern it that `[foo]{bar}` looks an awful lot like
`[foo](bar)` or even `[foo][bar]`. I realize the later two look very
similar, but as both indicate links, there is less for the reader to
get confused about. You're introducing a non-link syntax, so it should
probably look less like a link IMO.
That said, I'm going to ignore the 'looks like a link' issue for a
moment and add that I think I would prefer something like a reference
syntax with a datetime label:
Some text [30 May 2011] more text.
[30 May 2011]: datetime: 2011-05-30T15:00-07:00
The text is easier to read here, which actually provides a benefit
over just entering the raw html. Of course `[30 May 2011][]` or `[30
May 2011][some label]` could also work, although I don't know why
you'd want to use them.
Now if you can come up with a clean way to make that look less like a
link, I might be interested in using it myself. Otherwise, I'll stick
to raw html here.
[1]:
http://dev.w3.org/html5/spec/common-microsyntaxes.html#global-dates-and-times
[2]:
http://dev.w3.org/html5/spec/common-microsyntaxes.html#valid-date-or-time-string
[3]: http://dev.w3.org/html5/spec/text-level-semantics.html#the-time-element
[4]: http://maruku.rubyforge.org/proposal.html#attribute_lists
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On Tue, May 10, 2011 at 8:31 AM, Simon Bull waysoftheea...@yahoo.com.au wrote: Gentlefolk, I have been thinking on Markdown's lack of proper table support for a long while now. Here's where I have arrived... ## I Don't Like HTML Tables It is often argued that embedded HTML is the way to markdown rich tables. Unfortunately, this contradicts the higher markdown ideal that a raw markdown document (including tables!) should be good 1. Firstly for readers, 2. Secondly for authors, 3. Lastly for parsers which don't even rate a mention because markdown is for Humans. In response to this I will quote the paragraph from the syntax rules [1] which likely gave you this impression: Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text. Note that is says easy to read, write, and edit prose -- prose not tabular data. Taking this (along with the rest of that section of the document, it is clear (to me at least) that there is no place for a table syntax in markdown. Now, if you want to implement a third party add-on, fine. And if that third party add-on becomes popular, then maybe others will add it to there implementations as well. Maybe, eventually, if a single format becomes popular enough, the community at large will accept it. Until then, I'm not interested. If you want it, go build it! [1]: http://daringfireball.net/projects/markdown/syntax#html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ 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?
On Wed, May 4, 2011 at 9:03 PM, bucephalus org bucephalus@gmail.com wrote: Hi there! (1.) It may sound awkward, but I would like to use comments in Markdown texts. According to the rule that proper HTML works as HTML, I should be able to use !-- blablabla -- But the converters I use do strange things with comments. Is there an official rule about that? As you can see here [1], most implementations pass comments through. [1]: http://babelmark.bobtfish.net/?markdown=%21--++blablabla+-- (2.) I wonder if there is a recommended standard file extension for Markdown source files. For my own files I always use `.markdown`. But other important sources seem to prefer `.text`. Do you have an opinion on that, or is there even a standard? This has been a hotly debated topic in the past and IIRC J. Gruber (the creator of Markdown) has indicated that he will not support a standard and he personally uses '.text'. However, most projects I'm aware of use '.md' or '.markdown'. Personally, I prefer '.txt' or '.text' but notice what happened when I requested that github work with that [2]. [2]: https://github.com/mojombo/jekyll/issues/230 -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: CodeDown = Markdown as the universal language for program documentation
On Tue, Apr 12, 2011 at 9:04 AM, Rob McBroom mailingli...@skurfer.com wrote: On Apr 11, 2011, at 5:46 PM, David Chambers wrote: Check out Jeremy Ashkenas's docco. Truly beautiful. People might also be interested in appledoc, which uses Discount to parse comments. There is also Apydia [1], which uses Python-Markdown (or textile or reStructuredText) on Python code. However, the really powerful documentation library in Python (also supports C/C++ with other language promised to be coming) is Sphinx [2]. Unfortunately, is uses reStructuredText, not Markdown. Now, if someone created a similar tool that used Markdown, that would be something. The great thing about Sphinx is that while is can extract comments from the source, it is primarily meant to write documentation separate from the source - which should almost always be a projects primary documentation. The automatically-generated-from-source reference should usually be in addition to the primary documentation. At least, that is if you want a well documented project. [1]: http://apydia.ematia.de/index.html [2]: http://sphinx.pocoo.org/ -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
ol start with a specific number?
We recently received a request and working patch for Python-Markdown which adds support for starting an ordered list with the number given on the first line. For example: 3. Foo 4. Bar would result in ol li start=3Foo/li liBar/li /ol 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. My question is: should this be an option to turn on and off, and if so, should it be on or off by default? JG states in the docs: If you do use lazy list numbering, however, you should still start the list with the number 1. At some point in the future, Markdown may support starting ordered lists at an arbitrary number. Given that statement, it would seem that on by default and without an option to turn if off would be fine. 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? -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ 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?
On Thu, Dec 2, 2010 at 6:56 PM, David Chambers david.chambers...@gmail.com wrote: I'm not familiar with Text::MultiMarkdown, but I can say that I've found google-code-prettify to be a good fit with Markdown due to the fact that it acts upon vanilla pre blocks (unlike SyntaxHighlighter, for example, which only acts upon elements with a particular class name. David makes a good point. Although google-code-prettify is not the only client-side (javascript) solution out there. I did a write-up about such things a little while back. While that post does link to a number of solutions, its a rather long post mostly about why I think javascript solutions are the better choice, even if they don't (yet) always offer better output. [1]: http://achinghead.com/archive/88/syntax-highlighting-web/ -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: File Extension Consensus
On Sun, Nov 7, 2010 at 8:47 AM, Seumas Mac Uilleachan seu...@idirect.ca wrote: Since generally where needed the extension can be custom defined, why do we need a standard anyway? For this reason I have been silent on this issue. [^1] On 06/11/10 06:59 PM, Brett wrote: Here are the results from the limited data set provided. It looks like 'markdown' is the winner followed by 'mdown'. Third place is a tie between 'text' and 'md'. If usage sets a standard, then 'markdown' is the standard. However, I will say that standard or not, I doubt I will ever use markdown as a file extension. Call me lazy if you like, but I simply don't want to type that much every time. I prefer txt and if I must use something else (for example on github) I'll use md. Truth be told, in many situations I see no reason for any special designation. Docs for my projects on github are written in makdown and all have txt for file extensions. Yes, they then display as plan text. I don't care. If github some day adds a feature where they figure out I'm using markdown and convert my docs to html, that's fine too. On the other hand, while something like [Github Pages] does need to know what markup language a document is written in, it shouldn't need to rely on a file extension for that info. As Github Pages is just an instance of [Jekyll] (of which there are many clones) and Jekyll source files all require [metadata], and the metadata is always in the same format regardless of the markup language used, then the metadata could easily include the markup language used regardless of the file extension. Hey, then I could use .txt for everything. I think I'll go file a bug report with Jekyll. [Github Pages]: http://pages.github.com/ [Jekyll]: http://github.com/mojombo/jekyll/ [metadata]: https://github.com/mojombo/jekyll/wiki/YAML-Front-Matter [^1]: I can't help but notice that the other implementors have been silent as well. I suspect that in part it is because we have all had this discussion before. For some, because we really don't care.And in part, because it really doesn't matter. It's the later for me mostly. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Video syntax
On Wed, Sep 15, 2010 at 6:47 PM, David Chambers david.chambers...@gmail.com wrote: Of course, this markup applies to YouTube but may not apply to other services. That being the case, though, I'd still benefit from a `youtube:` solution since 80% or more of the videos I embed are YouTube videos. The fact that I'd need to include HTML for the other 20% does not deter me. I suppose personal projects have been implemented for much less convincing reasons. But if all your implementing is youtude support, then I'd call it that. `youtude:...` not 'video:...`. Although I suppose your trying to come up with a syntax for the more general use case and then move on from there to the more specific. I guess it's that general use case that I don't see the need for and the reason for my objection. With a clearer picture of what you actually what to accomplish, my objections have lessoned. One thing that I'd like to make clear, Waylan, is that I'm raising the issue on this list because it's a great place for such a discussion, not because I'm expecting any of the Markdown implementations to support such syntax. I guess I understood that. Sorry if that didn't come through in my response. I still see developing a syntax for video in general a waste for the reasons previously stated, so I guess I was trying to discourage a useless discussion, but if you're really only interested in a simple syntax to easily embed videos from youtube, vimeo and the like - and not necessarily expecting it to be an all encompassing solution for any embedded video, then I can see how that could be useful as third party add-on to markdown. And this is certainly the place to get good feedback on a solution. Last night another option occurred to me: `[Video: Soda Pop Stop](http://www.youtube.com/v/gPbh6Ru7VVM)`. The reason that I find this option so appealing is that the above remains valid Markdown in non-Mango contexts. Mango will perform preprocessing to convert this to the appropriate video markup, but without this preprocessing the line would simply be converted to a descriptive link. I actually like this. It introduces nothing new, will not trip up unmodified implementations of markdown and still provides enough clues to embed a video properly (assuming a known source is used). Despite what I said above, I suppose you would *not* want to do: [YouTube: Soda Pop Stop](gPbh6Ru7VVM) While that is more specific and won't create false expectations that the syntax will work for any type of video, it won't provide a useful link in an unmodified markdown parser. Perhaps as a safe middleground I'd suggest: [YouTube: Soda Pop Stop](http://www.youtube.com/v/gPbh6Ru7VVM) While I realize youtube can be extracted from parsing the url, by doing the syntax this way, it is more clear to users that this only works for supported known (and popular) video hosting sites. No false expectations about it working for every possible video out there. And maybe in the future when all those variables needed to embed html5 video tags are simplified, a more basic [video: ...] syntax could be adopted as well. I think that's the root of my concern. If you call it '[video:...]' you will get complaints insisting that every possible use case for embedded video be supported - which is just not practical today (as you acknowledge). But if you call it '[youtube:...]` or `[vimeo:...]`, etc., then if others want support for a specific as yet unsupported use-case, they can develop it themselves and maybe even provide their solution for public consumption. But hey, it's your project that you will be maintaining. What do I care? -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Video syntax
On Wed, Sep 15, 2010 at 9:24 PM, Waylan Limberg way...@gmail.com wrote: While I realize youtube can be extracted from parsing the url, by An interesting thought just occurred to be when re-reading this. Why do you need any special syntax at all? Why not just: [Soda Pop Stop](http://www.youtube.com/v/gPbh6Ru7VVM ) Just parse the urls for youtube.com (or vimeo etc) and when found, convert to an appropriate object. It's easy, simple and introduces no new syntax of any kind. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: A Modest Definition List Proposal
On Tue, Apr 13, 2010 at 3:21 PM, Tom Humiston t...@jumpingrock.net wrote: Found this unsent reply stuffed in my drafts folder... On 19 Feb 2009, at 6:48 AM, Michel Fortin wrote: Definition lists are already some sort of specialized niche syntax within Markdown and HTML: useful when you need one, but not something a lot of people care for or even know it exists. Definition lists are suitable for many kinds of term/value pairings, and not just definitions, but I had no concept of DLs as a flexible and handy semantic structure until I learned CSS. CSS encourages one to consider a document's *structure* (its HTML elements) as separate from its *presentation* (the appearance of those elements). I now regularly mark up, say, each workshop in a list as a DT, with its details (description, cost, meeting times, contact info) as DDs. Other CSS users may prefer to use unordered lists or the like, and sometimes I do, too. Is my use of DL appropriate? According to [Russ Weakley][1]: In this respect see the working draft for [html5][1]. In part is says: The dl element represents an association list consisting of zero or more name-value groups (a description list). It's called a description list! They're not even called definition lists any more. In fact, a number of examples on that page would not fit the definition model, but are considered completely appropriate for a dl. True, markdown is currently not specifically intended at a html5 tool (although it could be as valid html4 and valid xhtml are also valid html5), but given that html5 is to a large extent just a spec indicating how people and/or browsers are actually doing things, I see it an an admission that definition list was a bad (too restrictive) name for an otherwise useful feature. [1]: http://www.w3.org/TR/html5/semantics.html#the-dl-element -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On Fri, Mar 5, 2010 at 2:27 PM, Yuri Takhteyev qarama...@gmail.com wrote: I'll second that. Though it would be best if we could still use the Markdown name; a different one would just make one more confusing text-markup specification for people to ignore. If we could call it Markdown2 or something similar, it would be obvious that it expands on, and supersedes, the original Markdown. Required reading: http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1021 http://six.pairlist.net/pipermail/markdown-discuss/2008-February/thread.html#1031 http://six.pairlist.net/pipermail/markdown-discuss/2008-March/thread.html Of course, there are many many other relevant threads, but this would give you a taste. - yuri Yuri provided some good reading, but I thought it important to point out a specific comment by J.G. regarding the name of such a project: http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001189.html If anyone wants to undertake this effort, they may say it is inspired by markdown but they are going to have to name is something different. I get the impression that the name Markdown2 is not quite different enough here. There's another interesting comment he made regarding a specific markdown implementation here: http://six.pairlist.net/pipermail/markdown-discuss/2008-March/001163.html I don't point these comments out to discourage such an effort from happening (maybe it should). However, if it does happen, imo it will either need J.G.'s blessing or will need to happen separate from this community/list. Although, I would imagine an announcement of and link to such an effort wouldn't be objectionable. Additionally, I did not point those comments out in an effort to reflect negatively on J.G. He created Markdown and is entirely entitled to such a position. I would very likely take a simple position if I was in his shoes and/or shared his opinion. Currently, my opinion regarding the need for a fork/restart/refresh is 'undecided'. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On Fri, Mar 5, 2010 at 5:10 PM, david parsons o...@pell.chi.il.us wrote: In article 20100305211753.ga27...@protagoras.phil.berkeley.edu, John MacFarlane markdown-discuss@six.pairlist.net wrote: Currently big players like reddit and github use forms of markdown that depart significantly from John Gruber's official specification; Okay, I'm curious. Since I'm the writer of the forms of markdown that reddit and github use, just exactly where does discount depart significantly from JG's official specification? See this: http://github.github.com/github-flavored-markdown/ I think their assumptions about newlines is way off. But otherwise, the additions they added make sense in the context of that site. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: multiline header
On Mon, Mar 1, 2010 at 4:22 PM, Alexandre Leray alexan...@alexandreleray.com wrote: Hi, first of all thanks for such a great syntax, so far it's the best I know! I have a document with quite long titles and I was wondering if it was possible to hard-break them: You know, at first I was going to say that multi-line headers are explicitly forbidden. Then I checked the syntax document and it says nothing of the sort, However, as far as I know, every implementation works that way - probably because markdown.pl works that way. However, if they were supported, there would be a few ambiguities: Which of these are a multi-line header: Line one of header Line two of header = Line one of header = Line two of header = Currently, it is known by many authors that Markdown allows headers to not have blank lines before and/or after them. So, there could be documents in which the author intended the first line in the first example to be a paragraph - as it would be parsed now. And the author could have intended the second example to actually be two separate headers. Even hash header could have this problem: # Line one of header Is this line 2 or a new paragraph? In the thousands of existing documents out there, that second line is expected to be a new paragraph, not part of the header. 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. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
On Wed, Sep 9, 2009 at 12:18 AM, Suraj Kurapatisun...@gmail.com wrote: Hello, I read David Wheeler's table proposal[1] for Markdown and very much agree with his conclusion and PostgreSQL-inspired proposed format. I also read the mailing list archives for 2009 but did not find any clear concesus on whether DW's format was officially accepted (I hope it is soon!). I didn't go back and check but I think there was in a previous discussion with a similar proposal. In other words, you need to go back further in the archive. Basically, these proposals for more complex tables are outside the scope of Markdown and should be left to raw html. At least I seem to recall actual implementers leaning that direction. Of course, if someone wanted to implement David's proposal (or some variant) and users flocked to it, then the rest of us may follow suite. Until then, I'm sticking to the simple solution we have now. Hint (and shameless plug): Python-Markdown makes adding on something of the sort easy with it's extension API. Check it out here: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions What if Markdown used Unicode characters to express tables in this manner? All we need are two essential subsets of the Unicode box drawing characters: * thin ones for normal cells: ┌ ┐ └ ┘ ─ │ * thick ones for heading cells: ╔ ╗ ╚ ╝ ═ ║ The last few times someone proposed a syntax that didn't use commonly found keys on the keyboard, the proposal met with a *lot* of resistance. I suspect most users wouldn't even know how to type these characters. Another barrier is that not all implementations support Unicode (I think - at least not fully). Therefore, some implementations may never adopt such a proposal. Third, it seems like it would be an awful lot of work to build such a table. A lot more than some of the existing proposals out there. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 2:38 PM, Michel Fortinmichel.for...@michelf.com wrote: [snip] Are you sure this syntax is so intuitive? I was certain (for about 5 minutes) that you meant the colons to continue the cell from the previous line, not start a new cell, despite the weird result. What David Wheeler proposed seem to follow my interpretation. Basically, here's what I saw: [snip] And here's what I believe you meant: [snip] Which makes me believe my syntax above using explicit line separators may be better, even though it's much more verbose. Wow, I made the exact same mistake, except that I never caught on to what was really indented. In any event, the more verbose syntax proposed by Michael seems like the only reasonable alternative to me as well. That said, I am leaning more toward the opinion that anything more complex that can already be done should be left to raw html. But I've already explained my position on that before. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 9:45 PM, Waylan Limbergway...@gmail.com wrote: [snip] colon. In fact, it would seem reasonable to expect that the very implementations which correctly support definition lists (using colons) would be the first to implement any new alternate table syntax, whether it uses colons or not. Sorry, that was supposed to say ...which *currently* support definition lists... Apologies for any confusion my fat fingers may have caused. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: No Markdown in divs or tables ?
On Thu, Apr 23, 2009 at 3:15 PM, Dan Dascalescu ddascalescu+markd...@gmail.com wrote: What surprises me is the rationale of disabling Markdown processing in divs. Go re-read the first three paragraphs of the docs on inline html [1]. Processing markdown within divs just doesn't fit in with the purpose of markdown as stated there (i.e.: writing format v. publishing format). The fact is, a div, although meaningless in itself, is for publishing purposes. Therefore, if you really want it, markdown allows it - but your on you own. In other words, you have to write all the html inside it as well. Makes sense to me. [1]: http://daringfireball.net/projects/markdown/syntax#html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Python-Markdown 2.0 Final Released!
FYI, I just updated the wiki with all the 2.0 docs. Available Extensions is probably the most interesting page: http://www.freewisdom.org/projects/python-markdown/Available_Extensions Yuri, the front page needs updating, but it's locked out to block spammers, so I can't edit it. While your at it, change the download link on that page to PyPI: http://pypi.python.org/pypi/Markdown/2.0 Also, the available extensions page has some formatting issues. The wikilinks in a nested list aren't working. Looks like a bug in your wiki. On Mon, Apr 6, 2009 at 10:25 PM, Waylan Limberg way...@gmail.com wrote: I am happy to announce the release of Python-Markdown 2.0 final. We have versions for Python 2.3-2.6 and Python 3.0! See the release notes here: https://sourceforge.net/project/shownotes.php?release_id=674043group_id=153041 Download from PyPI here: http://pypi.python.org/pypi/Markdown/2.0 -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Python-Markdown 2.0 Release Candidate
I am pleased to announce that after much hard work, a Release Candidate for Python Markdown version 2.0 is now available for [download][]. Please, download it, install it, test it, beat it... and report any [bugs][]. Assuming no major bugs, we will release 2.0 final approximately one month from today. Until then, the project [site][] will continue to document version 1.7. Updated documentation is available in the `doc/` directory in the source files. Hopefully, all the included extensions will be documented before the final release. [download]: https://sourceforge.net/project/showfiles.php?group_id=153041package_id=183331release_id=666767 [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets [site]: http://www.freewisdom.org/projects/python-markdown Release Notes: === * Major refactor of the core and extension API. Extension authors should see the included documentation in `docs/writing_extensions.txt`. All parts of the syntax are now completely overridable by extensions. * Numerous extensions added to the standard distribution (off by default), including an extra extension which matches PHP Markdown Extra. See the `markdown/extensions/` directory for the full list. * The code has been refactored into a full Python library with a separate command line script. * Optional output of XHTML1 (default) or HTML4 with the option for extensions to add more. * Uses ElementTree to build (X)HTML document rather than home-grown NanoDom. * Most of the differences in Python-Markdown's output compared to perl and/or php have been eliminated. * And much more... See the changelog and [Git log][] for more details. [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Table of contents
On Thu, Mar 5, 2009 at 4:27 AM, Daniel Winterstein daniel.winterst...@gmail.com wrote: I'm using Markdown in an app and would like to provide support for including a table of contents. Any suggestions for a syntax? Has anyone done this before? Yes, Python-Markdown has an extension [1] that does this. Unfortunately, its not documented properly yet (it hasn't been officially released yet either), but it works on the same basic premise as your third suggestion. It uses all the headers to build a nested list and then either inserts that list at the location of the marker ``[TOC]``, or if the marker is not found, at the beginning of the document. [1]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/master/markdown/extensions/toc.py -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ 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)
On Wed, Feb 25, 2009 at 8:34 PM, Seumas Mac Uilleachan seu...@idirect.ca wrote: David E. Wheeler wrote: On Feb 25, 2009, at 6:57 AM, Sherwood Botsford wrote: Tables are critters where formatting is tangled with content. And with proportional type, a text only system requires agreement on tab spacing at minimum to get anything to look right. (I'm not a fan of monospace, so all these examples are wonky.) I think you might be using the wrong markup language, then. The use of monospace fonts is an expectation for reading Markdown. Really, it's the whole point. Wait, what? Monospace is an expectation?!? I have never used monospace in my e-mail programs. Isn't THAT the main expectation of Markdown? That it approximates e-mail writing? Well, I wouldn't say monospace is an expectation, but Markdown does rely heavily (perhaps more so than most) on whitespace. It just so happens that that whitespace is easier for the human eye to read when the text is monospace. However, yes, email is rarely written in monospace. Of course, on most cases, the white space is all at the beginning of the line (code blocks, lists) and the different levels of indent are still discernible when not in monospace. So, when the comment is made that the examples are wonky because they are not in monospace, then IMO, the proposed syntax fails. We all know that Markdown is to be readable first, writable second. If every reader of the document must read it in monospace, then that's not readable first - it's writable first. I'd also like to point out JB comments [1] that Markdown it supposed to cover only a common subset of HTML. If your trying to represent something more complex, then you need to use HTML. I would say multiline table cells fall into that more complex category. I know I'm never going to use any of this overly complex syntax that has been proposed thus far. I'll just write some raw HTML for my table and be done with it quickly. Don't get me wrong, if I have some vary basic tables that can easily be represented with the simplest syntax, then sure, I'll use something link PHP Extra's. Anything more than that will get raw HTML. [1]: http://daringfireball.net/projects/markdown/syntax#html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Tables
On Thu, Feb 19, 2009 at 4:16 AM, Daniel Winterstein daniel.winterst...@gmail.com wrote: @John: Thank you for pointing me to those table syntax ideas. They are all sensible, but look like hard work for the user. Since there is no standard, I'd like to suggest a couple of possibilities and get people's comments. Well, if I was to implement a table feature, I would just copy PHP's implementation. It's already well documented, in use, and has at least one copy (in MultiMarkdown) with embellishments. Why reinvent the wheel? Oh, and looking at your suggestions, they all look like a bunch of jumbled up randomly spaced text. Yes, I made sure my email client was set to fixed width, but still, my eyes couldn't follow the columns. As JG states, readability comes before writability, so we make the author add in the pipes (more work to write), so the reader can easily read it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: A Modest Definition List Proposal
On Wed, Feb 18, 2009 at 1:44 PM, David E. Wheeler da...@kineticode.com wrote: [snip] In a nutshell, I embrace the PHP Markdown Extra syntax, with one change: I would like to see the colon replaced with a tilde (for backwards compatibility, both should be supported). That means that a simple definition list would look like this: [snip] Comments? Has this ship already sailed? You make a convincing argument. And I must admit your proposal is very nice to look at/read/write. But if it ain't broke, don't fix it. The current implementation was set before I came along some few years ago, and I have never searched through the archives to see how it came about or why. But, people have been using it for this long without issue and there are already numerous existing documents out there that use it, so I see no reason to change it. In fact that last point (numerous existing documents) seems to be the de-facto response to any suggested changes on this list - and understandably so. No doubt that's why you suggested leaving the existing syntax in place, but then we would have two ways to define deflists. What happens when an author mixes the two? Ack! Yeah, this ship has sailed IMO. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Link syntax (was: definition lists?)
On Fri, Nov 21, 2008 at 10:43 AM, Thomas Nichols [EMAIL PROTECTED] wrote: Tangentially, I notice that this post by Waylan uses a link syntax which doesn't seem to be defined by http://daringfireball.net/projects/markdown/syntax#link but seems to work in some implementations at http://babelmark.bobtfish.net/ - that is, from the git repo [1] Actually, that syntax is a common shortcut used by many people in various mailing lists I subscribe to. Many of the people on these lists do not use (or perhaps even know) markdown syntax. I see it kind of a cross between ``[git repo] [1]`` and a footnote. I never expect these mailing list discussions to ever be feed through a markdown parser and don't go all out with the formatting. I use just enough to make it clear to the human reader in plain text without cluttering things up. For links, I find ``[1]`` works best in such situations and is the most commonly accepted approach in the circles I find myself in. I have concidered adding the ability to convert that syntax to links in Python-Markdown, but have not as the label would be wrong IMO. In the above example the result would be ... git repo a href=http://...;1/a ... when it should be: ... a href=http://...;git repo/a ... Although, now that I think about it, as the reference is removed by the parser, if the single bracketed text (``[1]``) is left alone in the text, it no longer has any meaning. That's probably worse that a link with a meaningless label. Perhaps Markdown should create the link when a reference for it exists. Although, I'd be more inclined to leave the brackets around the text to give it more meaning in the context: a href=http:...[1]/a or maybe [a href=http://...;1/a] That said, its not really a big deal to me, as I only ever use that syntax when I do *not* expect the text I'm typing (i.e.: mailing list discussions) to be feed through a markdown parser. As long as that's the case, none of the above arguments (for or against) are relevant as I see it. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Link syntax (was: definition lists?)
On Fri, Nov 21, 2008 at 11:36 AM, Jason Blevins [EMAIL PROTECTED] wrote: I couldn't find any discussion of it on the list, but here's the changelog entry: 1.0.2b2 - 20 Mar 2005 + Experimental support for [this] as a synonym for [this][]. Interestingly, this a completely different use for single-bracketed text than I use and see on a daily basis. As I mentioned before, I see it more as a shortcut footnote type syntax for links only when text is expected to be read in plain text format. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Link syntax (was: definition lists?)
On Fri, Nov 21, 2008 at 12:26 PM, Jason Blevins [EMAIL PROTECTED] wrote: Waylan Limberg wrote: On Fri, Nov 21, 2008 at 11:36 AM, Jason Blevins [EMAIL PROTECTED] wrote: I couldn't find any discussion of it on the list, but here's the changelog entry: 1.0.2b2 - 20 Mar 2005 + Experimental support for [this] as a synonym for [this][]. Interestingly, this a completely different use for single-bracketed text than I use and see on a daily basis. As I mentioned before, I see it more as a shortcut footnote type syntax for links only when text is expected to be read in plain text format. Thats a good point--I wasn't making the distinction before. Using numbers in brackets like so [1] is definitely a common notation for footnotes. I use it myself in emails but I didn't make the connection. It's also common for math and engineering journals to use that notation for references. Just to be clear, I'm not at all suggesting that markdown should adopt [1] at an alternate syntax for [^1]. I only ever use it for links in emails. I don't believe I said anything diferant than that, and no-one thus far seems to think I was, but I wanted to close that door before anyone opens it. Interestingly, that's how peg-markdown (with extensions via -x) renders footnotes. Instead of the link being a superscript '1', you get '[1]'. I actually like that better for the web I think. Superscripts are nice in print, but there you don't have to click on them. I have seen that before, and I have mixed feeling about it. It's a little easier to see them, but they also detract from reading the main text a little more than a superscript. Of course, they don't bother me in plain text emails, so it's no big deal. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Links and Message URIs
On Wed, Nov 19, 2008 at 8:50 PM, Mark Eli Kalderon [EMAIL PROTECTED] wrote: Here is a OS X message URI in angled brackets: message://[EMAIL PROTECTED] Markdown yields: pmessage://[EMAIL PROTECTED]/p Shouldn't it have given instead: pa href=message://[EMAIL PROTECTED]message://[EMAIL PROTECTED]/a/p Actually, it (sort of) does in a few implementations [1] . I can't speak for the others, but is works in python as a fluck. You see, the regex will only match the 3 schemes; ``http://``, ``https://``, ``ftp://`` as well as email addresses. As it turns out, the email regex for this case is rather dumb in the Python implementation and looks for any string between angle brackets (`` ``) that has an [EMAIL PROTECTED] in it. It just so happens that your example message does. That's why its encoded as html entities rather than plain text. Discount appears to behave the same. It looks like PEG Markdown is the only implementation that gives you what you want. Presumably most are seeing it as raw html and passing it through untouched, which explains why the angle brackets are not escaped. Only Pandoc escapes the brackets - which I would think is more correct that raw html treatment in this case. However, it is an obscure enough edge case, that the code would have to special case for it to not see it as raw html, that I wouldn't expect it to never work consistently. [1]: http://babelmark.bobtfish.net/?markdown=%3Cmessage%3A%2F%2F%253cE1KzXg9-Qb-3G%40smtp1.mail.ox.ac.uk%253e%3Esrc=1dest=2 -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: definition lists?
It's in the works. We had a working solution last week, but then refactored the core this week, so I have to refactor the definition list stuff. If you want it right now, your free to checkout from the git repo [1] at commit e968bbf (on Nov 6), or wait a few more days for me to get the refactor done and have the latest and greatest. One thing is for sure, I will have something included in the next release which I anticipate happening soonish. [1]: http://gitorious.org/projects/python-markdown/repos/mainline On Fri, Nov 14, 2008 at 1:26 PM, Andreas Åkre Solberg [EMAIL PROTECTED] wrote: Any way of writing definition lists? Andreas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
On Sun, Sep 7, 2008 at 9:24 PM, John MacFarlane [EMAIL PROTECTED] wrote: I'm curious how people think the following *should* be interpreted: - one 2. two Personally, I would prefer C. For what it's worth, I'm also one of the few that seems to think anything less than 4 spaces of indentation should be ignored in the list syntax - but that's another discussion we've already had. I'm just saying that may be part of the reason why I completely rule out option B. Given the general lack of polarity of my opinion on the indentation issue, I'm guessing most wouldn't like C for the same reason, even if it is the only way *my* brain parses that list. 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. Personally, I'm the type that's going to renumber the items anyway, but I suspect that's why option A is the most popular among current implementations. I realize the actual numbering is irrelevant to an ordered list, as long as the numbers are there, but it's about what's more readable and I suppose out-of-order numbering is less readable to some than the above mixed list. Readability really is the issue here and for those that don't want to so strictly enforce indentation I can see how option B looks logical, but for the above to work, then the converse also needs to work (perhaps not technically - but for consistency) which forces us to only accept option A - even if it's not my personal favorite. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
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. 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. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
On Mon, Sep 8, 2008 at 12:27 PM, [EMAIL PROTECTED] wrote: if they are ambiguous about what they want, do nothing! While, generally, I would agree with this line of thinking, we must remember that one of the basic concepts behind Markdown is that it should never return an error for invalid markup. So, then, how do we interpret do nothing. Some would argue that do nothing is what Option A is doing, while other's might argue the same for Option C. Or would you prefer option D: wrap the entire block of text in a p and move on? The fact is, the authors of each implementation need to make that decision. Obviously, everyone hasn't made the same decision. Yet, theoretically, all implementations *should* do the same thing. So, yeah, we need to have this discussion. That said, I think you do have a point. Option B does not fit into do nothing no matter how you look at it. That's one more strike against IMO. I also think that the above option D it not only a lot harder to implement, but also not intuitive at all. At least with A, B or C, the user can look at the resulting list(s) and get a few clues about what might be wrong in their source text. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: list corner case
On Mon, Sep 8, 2008 at 1:48 PM, [EMAIL PROTECTED] wrote: waylan said: So, then, how do we interpret do nothing. nothing is exactly as john put it in his e-mail: - one 2. two Well, as any generated output (anything except raw html) should be valid html, at the least it would be wrapped in some container (could be a p or div or something). More realistically, as I understand how most of the parsers work, I would expect such a drastic interpretation of do nothing to be: ul lione 2. two/li /ul That is, the second line is simply seen as a continuation (another line) of the first list item as it does not start with indentation (indicating nesting) or a matching list item indicator (indicating another item of the same type). In other words, if the line does not start with the *same* list item type it is seen as a line of plain text - no different than: - foo bar We'll call this Option E. I'd argue that this would actually be a dumber parser than a true do nothing solution as the truly do nothing parser would need knowledge of, and code to test for the special case and act differently (as Yuri points out, that's ugly - I know I wouldn't want to write the parser for that), whereas option E just dumbs the parser down a little. This would also present an interesting solution to the I want two or more consecutive, but different lists in my document problem. Consider: 1. one 2. two * foo * bar - blah - baz No more of that must use two blank lines between each list monkey business that we've discussed before and no-one has bothered to implement. Which, btw, is another reason why I like C better than A. Either C or E works for me, but I'll settle with A as a lousy compromise seeing it already appears to have the popular vote. -- Waylan Limberg [EMAIL PROTECTED] ___ 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
On Sat, Jun 7, 2008 at 11:42 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: [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: Well, first of all, he's using an old version of Python-Markdown. The first line of his `render` function gives it away (due to the change in 1.7 to all-unicode -- you generally don't pass unicode text to str()) body = str(markdown.Markdown(text)) Just use the wrapper (all lowercase in any version): body = markdown.markdown(text) IIRC, there was a bugfix in 1.7 that also addressed the raw html wrapped in p tags thing. So, upgrade to 1.7 and that problem should go away. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Fenced-Code-Blocks in Python-Markdown
On Mon, May 12, 2008 at 6:58 AM, Már Örlygsson [EMAIL PROTECTED] wrote: precode class=htmllt;pgt;Hello World!lt;/pgt; /code/pre It would be a much better idea to place the class-name on the outer element (`pre`) I had initially intended on doing that myself. However, I figured support for Highlight.js would be more important. Besides, while I generally like styling hooks on the outermost level in html, I can't imagine any benefit in this scenario. And when you think about it, it is the code that determines the styling, so logically the code tag should get the styling hook. I suspect that was the reasoning behind Highligh.js. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Fenced-Code-Blocks in Python-Markdown
I'd like to announce a beta release of the Fenced-Code-Blocks
Extension for Python-Markdown.
http://www.freewisdom.org/projects/python-markdown/Available_Extensions
The latest code for Python-Markdown and packaged extensions are now
available on Gitorious.
http://gitorious.org/projects/python-markdown
The same syntax is used as the just released PHP Markdown Extra 1.2. I
did add the option to define a class on the block for language
identification. Here's an example:
pHello World!/p
{.html}
Becomes:
precode class=htmllt;pgt;Hello World!lt;/pgt;
/code/pre
This should work nicely with Highlight.js [1] if one so desires. Of
course, as this is optional, if you leave the class definition off, it
works like PHP Markdown Extra. Unfortunately, including the class
definition makes PHP Markdown Extra fail to match the block. Consider
yourself warned.
[1]: http://softwaremaniacs.org/soft/highlight/en/
On Sun, May 11, 2008 at 8:31 AM, Michel Fortin
[EMAIL PROTECTED] wrote:
[snip]
This new version of PHP Markdown Extra adds support for fenced code blocks
(which I was previously calling flat). Fenced code blocks overcome many
limitations of Markdown's indented code blocks: they can can be put
immediately following a list item, can start and end with blank lines, and
can be put one after the other as two consecutive code blocks. Also, if
you're using an editor which cannot indent automatically a selected block of
text, such as a text box in your web browser, it's easier to paste code in.
[snip]
Extra 1.2 (11 May 2008):
* Added fenced code block syntax which don't require indentation
and can start and end with blank lines. A fenced code block
starts with a line of consecutive tilde (~) and ends on the
next line with the same number of consecutive tilde. Here's an
example:
Hello World!
[snip]
--
Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown Extra Specification (First Draft)
Sherwood, First of all, realize that Michel is currently documenting existing behavior. I like some of our suggestions, but they should have happened years ago when the discussion happened here on the list. Various other implementations have copied the existing behavior and there are countless documents already using them, so I doubt we'll see any changes, unless we move to Markdown 2.0 or something. I get the impression that's not likely any time soon. Anyway, there were a few things I'll comment on individually: On Tue, May 6, 2008 at 6:18 PM, Sherwood Botsford [EMAIL PROTECTED] wrote: As a suggestion for the next pass at this, add an example of each, and how it should be rendered. I agree. I was going to make the same suggestion. This would be helpful. [snip] 2.2.2 Abbreviation Again, I'd like a hook so that I can put these in an external file. In my tree farm web page I'd like to use botanical descriptions, but be able to let users see the definition on mouse over or click. But the word 'glabrous' may appear on 40 pages. Be nice if I only had to define it once. If someone is creating an annotated Shakespeare they would want to use an Elizabethan English dictionary as their external file, style it so that defined words are barely different from the text, and let the confused reader click for enlightenment. An excellent idea! After all, I had the same idea some time ago and implemented it in the Abbreviation Extension [1] for Python-Markdown. However, I'm not sure this should be a requirement of a syntax specification. [1]: http://achinghead.com/markdown/abbr/ As I noted above, the rest I'll leave to existing behavior, even if I like your suggestion better. We don't want to forget J.G.'s motivation and goals for creating markdown to start with. A review of that will answer some of your questions about current behavior. And, we must also never forget the (even as implementors) we should not care so much about how hard it is to implement if it makes if easier (and more permisive/relaxed) for the document author. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Feature Request External label resolution
On Sun, Apr 20, 2008 at 1:25 PM, Sherwood Botsford [EMAIL PROTECTED] wrote: Umm. Pointers to Markdown implementations with support for extensions? [Python-Markdown][1] has an [extension api][2]. Interestingly my [Abbreviation Extension][3] for Python-Markdown does something similar for abbreviations. Given an external file, it pulls all abbr defs and uses them in processing the source file. It wouldn't be hard at all to adapt it for link defs. What I really like about it is that the external file can be any text document (markdown or otherwise) and the limited parser will only extract the abbr defs (one per line) from it. [1]: http://www.freewisdom.org/projects/python-markdown/ [2]: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions [3]: http://achinghead.com/markdown/abbr/ -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
HTML entities in URLs and urlencoding
We recently received the following bug report for the python-markdown implementation: The are escaped in URLs. An example: [Link](http://www.site.com/?param1=value1param2=value1) Should output: a href=http://www.site.com/?param1=value1param2=value1;Link/a Currently outputs: a href=http://www.site.com/?param1=value1amp;param2=value1;Link/a So the must not be escaped! A fix is easy, but it occurred to me that perhaps links should be urlencoded -- at least some chars should be. Specifically the unsafe chars listed in RFC 1738 [1]. The reserved chars probably should too when not used in their approved manner (i.e.: A colon should only be allowed after the scheme (http://) or in the location (usr:[EMAIL PROTECTED]:port) but should be encoded anywhere else). Of course, that involves extra work. So I went to check what other implementations do [2] and discovered that every one escapes with html entities. Is there something I'm missing or is this a bug? As far as I can tell, the amp; breaks the query string. [1]: http://www.rfc-editor.org/rfc/rfc1738.txt [2]: http://babelmark.bobtfish.net/?markdown=%5BLink%5D%28http%3A%2F%2Fwww.site.com%2F%3Fparam1%3Dvalue1%26param2%3Dvalue1%29normalize=onsrc=1dest=2 -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: HTML entities in URLs and urlencoding
On Mon, Mar 31, 2008 at 9:53 PM, Milian Wolff [EMAIL PROTECTED] wrote: [snip] So the must not be escaped! It must! See also http://htmlhelp.com/tools/validator/problems.html#amp Doh'! I knew that. Of course, I just typed a url with an amp; in my address bar and it didn't work. Now I feel like an idiot. Thanks for bringing me back. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Bug?
On Sat, Mar 29, 2008 at 4:52 PM, Mark Eli Kalderon [EMAIL PROTECTED] wrote: Hi, This might be related to the bug reported earlier about parsing URLs with parens, but the following looks like a bug to me: [ZIP archives](http://en.wikipedia.org/wiki/ZIP_(file_format) ZIP (file format) - Wikipedia, the free encyclopedia) gets rendered by Markdown 1.01 as: [snip] According to Babelmark [1] its fixed in 1.02b8. Although I see a few other distributions get this wrong too. Thanks for the report. [1]: http://babelmark.bobtfish.net/?markdown=%5BZIP+archives%5D%28http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZIP_%28file_format%29+%22ZIP+%28file+format%29+-+Wikipedia%2C+the+free+encyclopedia%22%29normalize=on -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: HTML5's audio/video and Markdown
On Tue, Mar 18, 2008 at 1:59 PM, Aslak Raanes [EMAIL PROTECTED] wrote: Does anyone have any toughts on how one should be using video audio with Markdown? Using the link or the img syntax? Other suggestions? This would fall under raw html. You should simple write your own html directly in the markdown document just the way you want it. The parser will pass it though unchanged. If you question this answer, go re-read the [Inline HTML][] section of the syntax rules. The way I read it, this is the only appropriate solution. [InlineHTML]: http://daringfireball.net/projects/markdown/syntax#html -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown doesn't always generate XHTML
On Fri, Mar 14, 2008 at 3:20 PM, Joseph Lorenzo Hall [EMAIL PROTECTED] wrote: On Fri, Mar 14, 2008 at 12:11 PM, Milian Wolff [EMAIL PROTECTED] wrote: I have two issues with this: 1. The script tag isn't closed, which means it's not valid XML (and thus not valid XHTML). This is a bug in my eyes. Is it markdown's business to correct bad markup input (which, I understand, it ignores)? Right, raw html (or anything which looks like html - pretty much anything between and ) is simply passed through unchanged. If the input is not valid, then the output will not be either. That is known and expected behavior. I'd say a feature! Definitely NOT a bug. Now, if you want to put your own mechanisms in place to address that, either before or after markdown is run, you are more than welcome to do so. Regarding the security issues, I understand your concerns, but there are some situations were all document authors are trusted (authenticated) users and have a legitimate need for that feature. We can't cut them off for everyone else. However, I know that Python-Markdown has an option to not allow any html in a document (this safe_mode can be set to either replace with a customizable message, remove completely, or escape the html). Of course, to stay in line with the Markdown standard, it is off by default, but very easy to turn on in your code. Other implementations may offer a similar option. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Javascript in URLs (was: Markdown doesn't always generate XHTML)
On Fri, Mar 14, 2008 at 11:22 PM, Michel Fortin [EMAIL PROTECTED] wrote: Safe mode you say? Yeah, well, I didn't paint that bike shed. PHP Markdown also has a no-markup mode which would filter script tags and any other HTML tags. But this doesn't prevent anyone from inserting their own script on the page. Do you know you can inject a script in a URL? Guess what this does: [link](javascript:alert%28'Hello%20world!'%29) This is a good point, and something I hadn't thought about myself. I would think that markdown should *not* allow that regardless of any safe/no-markup/whatever-you-call-it mode. If someone legitimately wants javascript in their links/images/etc then they should be writing raw html. What do you think? Of course, then how do we do that? Some possabilites I came up with without much thought: 1. Trunicate a url at javascript: 2. Completely remove the entire url (perhaps replace with blank string or #) 3. Leave the markup for the entire link as plan text (in other words - its not considered a match) 4. Do some kind of escaping (not sure what at this point) and leave it in the url -- Waylan Limberg [EMAIL PROTECTED] ___ 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
On Fri, Mar 7, 2008 at 5:17 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: 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. And if they don't care why should we? Seriously, if the author can't be bothered to check his work and fix any errors, then I don't care either. Sure, I may be annoyed when I read the document later, but now I know how much effort s/he put into it. If it's obvious the author doesn't care about it, then I probably won't be so easily persuaded by the point s/he's trying to make. I'd say there's no harm done. -- Waylan Limberg [EMAIL PROTECTED] ___ 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
On Thu, Mar 6, 2008 at 9:39 AM, Seumas Mac Uilleachan [EMAIL PROTECTED] wrote: Aristotle Pagaltzis wrote: * 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 Ah, so your assuming the parser should automatically close unclosed tags much as a browser in quirks mode does. Sure, you and I understand how that works, but should we expect authors who are unfamiliar with html to get that? I doubt it. I also suspect that it's those same authors that will most likely purposely write a document containing text formatted like that. I agree with Seumas that such people would expect: 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 Yeah, I think we should force authors to close any tags they open. If they don't, then the text is assumed to be literal, not markup. Maybe that's too restrictive for some peoples taste. But that's what I see when I look at that text. 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. If we want to throw valid markup to the wind, then sure, Seumans first suggestion (and how markdown.pl currently works) is the answer. Otherwise, any one of my suggestions could be the anwser. This tells the author (who hopefully is previewing anyway) that they have an error in their markup and need to make a change. With Aristotle's suggested output, those unfamiliar with html will, IMO, not be able to easily discern why the output doesn't match their expectations. However, by leaving some of the markup literal, they have some clues to work with. 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! -- Waylan Limberg [EMAIL PROTECTED] ___ 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?)
mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg [EMAIL PROTECTED] ___ 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?)
On Fri, Feb 29, 2008 at 12:14 PM, Joseph Lorenzo Hall [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 8:52 AM, Thomas Nichols [EMAIL PROTECTED] wrote: Having a spec/ruleset/syntax definition seems an admirable goal; does this necessarily imply that, for example, you should not be able to begin a list item with zero to three spaces, at your discretion? This seems rather at odds with the overall theme of your mail, with which I heartily agree. [snip] Markdown sees that 2008. as a list item. And this is why I think the spaces should go. It leaves things a little *too* ambiguous. In any event, this thread is not about list syntax, but whether we want/need a new spec/rule set. I knew the list issue would bring a few more opinions to the table, so thanks for sharing (yeah, it was bait). Sometimes, as one of those implementers I have to remind myself of that originating philosophy behind Markdown. That's the only thing keeping me from making the implementation I work on more strict. Well, the only thing except those real world use cases like the ones all those people passionate about keeping whitespace before list items have. Btw, the more I think about this, the more I don't see a *need* for a new rule-set as much as I *want* one. When looked at in the context of the philosophy, the current rules pretty much stand on their own. However, a central (perhaps non-implementation specific) location for various extensions (alternate behaviors) to define their syntax would be nice. -- Waylan Limberg [EMAIL PROTECTED] ___ 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?)
On Fri, Feb 29, 2008 at 6:18 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: [snip] Thanks Aristotle. You bring up may good points which I will not argue with. That post was meant to generate conversation and you, among others bit the bait (although you may have bit a little harder). These are all things we need to discuss and consider if and when a spec is developed and I hadn't yet seen that conversation yet. Additionally, I may not have used the best words at times and you called me on that, so thank you. -- Waylan Limberg [EMAIL PROTECTED] ___ 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)
On Fri, Feb 29, 2008 at 5:46 PM, Thomas Nichols [EMAIL PROTECTED] wrote: tough. In this instance, though, I haven't yet understood why Markdown should not continue to support the following from the [syntax page][], List markers typically start at the left margin, but may be indented by up to three spaces. List markers must be followed by one or more spaces or a tab. Hmm, I don't remember reading that before. Was it always there? Anyway, to be honest this has been the hardest thing about markdown for me to wrap my head around (and probably why I picked it as an example in the other discussion). The way I always understood it, indenting in Markdown is done in increments of 4. Therefore, in my mind, the only amounts of indent allowed should be 0, 4, 8, 12, 16, ... and so on. It would never even occur to me to use any other amounts of indent for any reason - ever. And, in fact, I had never tried it until someone brought it up here on the list. With the exception of the it makes copy and pasting easier argument, I'll probably never understand it. Thats just the way my mind works. Nothing against those who think differently. And, in fact, reading Gruber's Dive into Markdown it would seem reasonable that one could conceivably take any well crafted email and run it through a markdown parser and get some decent html. Obviously, in practice things don't work so well. In the end consesions have to be made on both sides. I won't enforce my restrictive view of indentation on the community at large, and perhaps those who like to indent secondary lines of list items will need to watch their line breaks to avoid errant list items. We could always require a blank line between list items, but consider this list of one-word items: * red * blue * green Do we really want to require the author to add a blank line between each item? I don't. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Whitespace in img src
On 25 Feb 2008 16:45:23 -0800, david parsons [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Florian Lindner markdown-discuss@six.pairlist.net wrote: Hello, markdown (Python implementation) seems to render:  to img src=pfad/und/eine title=lange/url zum bild.jpg alt=alternativer text/ breaking the URL at the whitespace. AFAIK whitespaces are ok in URLs so why is it breaking up the URL here? Because spaces are how it separates the url from the title text? Yup, thats why. Although quotes are acceptable as well. The only way to do the encoding of spaces is to always require quotes around the title text. A quick look at the syntax rules indicates that quotes should always be required and I could change python-markdown's behavior to follow. However, there may be a significant number of documents that have been created over the years that rely on the use of a space only to separate the title. A change of that behavior would break all those documents. On the other hand, url's with spaces would be very unusual and are generally considered a bad idea, so I'm not inclined to NOT make that change unless I get sufficiant demand for it. Perhaps the other python-markdown dev would feel different. Personally, I'd suggest a change in your urls. Perhaps replace the spaces with the underscore `_`. If that's not possible or beyond your control, then encode the urls manually. If you really must have the spaces, then it would be *vary easy* (relatively speaking) to write your own extension using python-markdown's extension api. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: spelling with g?
On Wed, Feb 20, 2008 at 1:19 AM, Petite Abeille [EMAIL PROTECTED] wrote: On Feb 20, 2008, at 4:30 AM, Michel Fortin wrote: Markdown specifically allows you to use HTML in the middle of your prose. g looks like an HTML tag, Markdown recognize it as such, and you get it as an HTML tag in the output. Hmmm... yes... but... g is not a HTML tag... shouldn't it be escaped automatically much in the same way as g would? And whoever said we should limit this feature only to HTML? Python-Markdown has within that last couple months received 2 bug reports from people who were running their templates through markdown. As least one was an xml based template (Mako I believe). These people are creating templates with the template syntax using %foo style tags and markdown among those tags. They then run the template through markdown to get html and template syntax, which is then run through the template engine to produce the final document. At first I found this very strange, but on further reflection, I suppose it is easier to edit markdown text than html, especially when it's mixed with a xml variant. I say variant because %foo isn't really xml. It's also why I personally don't like xml based template syntaxes, but that's beside the point. The fact is, there are real-world uses for any xml type tag being passed through markdown unchanged. As a side note, like php Markdown, Python-Markdown also has an alternate behavior for raw html. In fact, version 1.7 (released Monday) adds the ability to *escape* all raw html instead of removing it, which would provide your desired behavior. Of course it would also affect valid html tags in your documents. However, with the simple extension api, it would be easy to override that behavior with your own. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown RFC?
On Feb 18, 2008 5:59 PM, Andrea Censi [EMAIL PROTECTED] wrote: On Feb 18, 2008 2:31 PM, Petite Abeille [EMAIL PROTECTED] wrote: Has anyone considered writing a formal specification for Markdown? Yes, it's called Markdown.pl g. I have to respectfully disagree. Mr. Gruber himself has said a few times on this list that just because markdown.pl does something doesn't mean it's right. In fact, my recollection is that he indicated the syntax rules are the final authority and that markdown.pl fails in some instances. Interestingly, most of the direct ports fail in those same instances. Sorry, I can't recall any specific example at this time as I don't use one of those direct ports. Of course, the problem is that the syntax rules are a little vague from time to time and in some instances are open to multiple interpretations. However, given the philosophy behind why J.G. created Markdown, I don't know that such a strict specification is desirable in this instance. If you search the archives, you'll find previous discussions on this. -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: footnote syntax
I also was not around when the current syntax was proposed, but I personally find the caret very intuitive due to its association with superscripts. I immediately connected the two upon first seeing it, and have never had to check a reference for that little tidbit again. Now, I suppose if one has never seen the caret represent a superscript in other contexts, it may not be quite as clear. Even so, the caret looks much like an up-arrow, so why not? On Feb 8, 2008 7:10 AM, Michel Fortin [EMAIL PROTECTED] wrote: Le 2008-02-08 à 2:26, Richard Taytor a écrit : I searched the list but didn't find an answer to this question. Why is the caret[^c] preferred over the asterisk[*a] for footnote markers? [^c]: http://en.wikipedia.org/wiki/Caret [*a]: http://en.wikipedia.org/wiki/Asterisk I'm not the one who came up with the syntax in the first place, but I think it's clearer to use a new character rather than overloading the asterisk with yet another meaning. Also, to me at least, ^ evokes the exponentiation operator which is represented as superscript in mathematics, which in turn could make me think of a superscript footnote marker. Michel Fortin [EMAIL PROTECTED] http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Entity conversion glitch?
I would say this is a minor bug, and an interesting edge case as well. The cause is the semi-colon following the `T`. `T;` looks like an html entity. If you remove the semicolon, the `` is properly converted to `amp;`. In python-markdown, you can escape the `` and you will get the expected output: under a license from AT\T; however, others were based on BSD instead. becomes: punder a license from ATamp;T; however, others were based on BSD instead. /p Unfortunately, this does not seem to work in the other implementations. On Feb 3, 2008 12:22 PM, Petite Abeille [EMAIL PROTECTED] wrote: Hello, Given the following text: under a license from ATT; however, others were based on BSD instead. Daring Fireball's Markdown Dingus produces: punder a license from ATT; however, others were based on BSD instead./p Note how the '' is not escaped to 'amp;'. Bug? Feature? Thanks in advance. Kind regards, PA. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: replacing with quot;
Thanks for the feedback guys. I just wanted to make sure I wasn't missing anything before commiting the change. Oh, and Michel, thanks for the reminder about attributes. Python-markdown's dom should make that easy to do. On Jan 5, 2008 10:29 AM, Yuri Takhteyev [EMAIL PROTECTED] wrote: I agree with Michel, that it's better to not escape things where it's not necessary. If you want to fix it, the place to do is the method Document.normalizeEntities(), which is now called in two places: 1. in Element.toxml() separately for each attribute 2. in TextNode.toxml() for the whole thing The quickest fix would be to add an extra keyword parameter to this function: something like skip_quotes and call with this parameter in the second case. Note that , , and need to be replaced in both cases. - yuri On Jan 5, 2008 4:51 AM, Michel Fortin [EMAIL PROTECTED] wrote: So, my question is: Which implementation do you consider correct and why? I'd say both are correct since, within HTML or XML character data, a character entity is semantically equivalent to the litteral character it represents. But for the sake of compatibility with other processing tools, I'd avoid using an entity for strait quotes (or any other character for that matter) when it's not necessary. -- http://sputnik.freewisdom.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Waylan Limberg [EMAIL PROTECTED] ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
