Re: let's get this established, one way or the other, once and for all
First off, I did not trot out a one-line post to put you in check. I subscribed to this list to keep up-to-date on the world of markdown. Like David, I too find the discussions about markdown parsers interesting. Unfortunately I usually have little to add to them because I am not a programmer. Your post however was a rambling soliloquy on the advantages of using blank lines for markup because it apparently doesn't confuse the users. That type of markup is very prevalent in your z.e.n. system (yes, I have looked at it), but is limited in markdown. So I was confused about what the relevance to markdown was. You continually do go on about this using blank lines but that is not something that will be incorporated into markdown as you envision it. Thus, as a user, I was confused, which you claim to want to avoid. Since you don't seem to want to enlighten me on the relevance of this to markdown I guess I will just remain confused, and since of late the majority of the discussions on this list seem to be centered around either your ramblings on using blank lines or on the state of affairs for markdown on the app store (presumably that has something to do with the Mac), neither of which interests me, I will just resign from the list and let you win. Yay you. On 12/04/2011 04:50 PM, bowerb...@aol.com wrote: seumas said: What confuses me is what this all has to do with markdown. david said: I find discussion of techniques for building Markdown parsers very interesting. i can justify myself. indeed, it's a good exercise every so often, just to ensure that your position and directionality are focused. but it's not right, or fair, that every month, someone regularly trots out a one-line post essentially trying to put me in check... so let's get this established, one way or the other, once and for all. the two sides are sufficiently clear, i think, from the quotes above. so register your vote on the issue, either with seumas or with david, along with a sentence or two summarizing your position, if needed. (or write an essay, if you want, it's all the same to me; but do vote.) we'll leave the polls open through wednesday, unless a clear winner hasn't emerged by then, in which case we'll extend it through friday. -bowerbird ___ 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: and life goes on
Unfortunately this is apparently becoming the norm here. There's off-topic stuff, fits and starts of conversations about forking/rewriting/expanding/standardizing markdown, and very occasional questions about usage or edge case problems. Fortunately (for me anyway) markdown just works. On 10/14/2011 06:02 PM, Christian Sciberras wrote: I'm starting to think I subscribed to the wrong mailing list. Either that, or someone else did. Then again, I know I'll be well-informed about deaths of (someone's) heroes... *sigh* On Fri, Oct 14, 2011 at 11:45 PM, bowerb...@aol.com mailto:bowerb...@aol.com wrote: they say that deaths come in threes... for me, it was these: 1. scott wannberg, los angeles poet, one of my favorite performers 2. michael hart, founder of project gutenberg, icon and iconoclast 3. steve jobs, seemingly the only guy who made stuff work correctly i'm sure that for others, dennis ritchie is on their list, for his own trio: 1. c 2. kr 3. unix godspeed to all of these people, who are heroes just as much as any firefighter or soldier, heroes of creativity and the imagination. and a hearty chill out to anyone who thinks this is off-topic... *** meanwhile, life goes on... it seems that fletcher finally received his app-store blessing, so we can hope that we will see multimarkdown composer soon... which means i can come out with my little tool as well. :+) my editor uses z.m.l. (zen markup language), not markdown, but it's close enough that you might want to take a look at it anyway. if anyone wants to alpha-test it, just let me know backchannel... it's cross-platform to the mac (even very old ones), p.c., and linux. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto: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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Metadata syntax (was Universal syntax for Markdown)
Oh My God I actually agree with Big Bird here. This whole discussion is getting far beyond what I think of as a lightweight markup system. Personally I think metadata should be processed separately from markdown data. Keep it unixy - one tool, one job. On 09/20/2011 01:03 PM, bowerb...@aol.com wrote: sherwood said: Well if your dogs are like mine, they will eat practically anything. Lately in addition to their kibble they've been catching pocket gophers and mice. A border collie is much less lovable with 'mouse breath' gophers and mice taste _great_ to a dog -- a dietary delicacy for many millennia now... it's your kibble they don't really care for. its redeeming feature is that it's so _easy_. but i bet there are several brands of kibble which your dogs still turn up their noses at. as the ad man replied, when asked why his costly campaign hadn't moved more units of the client's dogfood: dogs hate its taste. people are the same way. they'll eat a _lot_ of things, including some that you consider to taste _dreadful_ (e.g., ms-word), but that does not mean that they will eat _anything_. *** anyway, this conversation sounds confused... aside from questions of philosophy, it seems to me that there is confusion about just what sort of metadata we're all talking about, and how it's used, by whom, for what purposes... and so on and so forth, and hmm baby swing. but maybe i'm the only one confused...:+) you all seem like bright competent fellows, so i'm sure you'll get it all worked out, so i'm gonna go back to my sandbox and play. have a nice day... -bowerbird ___ 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: uniform type indicator
On 08/05/2011 05:55 PM, Dan Katri wrote: I don't think you can blame him for saying this on his blog where it will reach millions. I'm pretty sure everyone on this mailing list reads daring fireball. Well, ALMOST everyone. Frankly there are NO blogs that I read, only ones that I find searching for a specific topic. Then I read that specific entry. I also can't be bothered with twitter ... On 5 Aug 2011, at 20:32, Andy Lee ag...@mac.com mailto:ag...@mac.com wrote: As Bowerbird pointed out in an earlier message, there has been a rise recently in Markdown apps. I would guess the people asking have been among the developers of those apps, and I would guess they have included developers prominent enough to get his attention. I saw the following exchange on Twitter recently between Gruber and the developer Gus Mueller. I don't have any more context than this: = ccgus: @gruber UTI. Markdown. UTI. Hint, hint. UTI. [http://twitter.com/ccgus/status/98870955245441024] = gruber: @ccgus Shit, forgot about that. Will do tomorrow or tonight. [http://twitter.com/gruber/status/98909687612837888] = As for Gruber not posting here, my gut feeling is that he has no interest in contributing to Markdown (or any other project) in any technical way, even to set direction or endorse a successor. The nearest thing you'll get to a public feedback mechanism is to mention @gruber on Twitter or to use http://daringfireballwithcomments.net (Safari only). --Andy On Aug 5, 2011, at 2:56 PM, Alan J. Hogan wrote: Anyone know what or who prompted this? Alan On Aug 5, 2011, at 11:36 AM, bowerb...@aol.com mailto:bowerb...@aol.com wrote: this is fascinating: http://daringfireball.net/linked/2011/08/05/markdown-uti i don't know (and don't care about) any possible significance of such a pronouncement on a uniform type indicator, but i think that it's interesting that gruber has decided to make _any_ type of statement on markdown, with the big moves now underfoot, and doubly so when he chooses to communicate it via his blog -- which is public, but has zero public feedback mechanism -- and not also here, where markdown developers hold discussions. this is not a judgment -- of any type -- merely an observation... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto:Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto:Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto: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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: markdown conversions
On 06/26/2011 02:36 PM, bowerb...@aol.com wrote: If we were only worried about markup we'd just use html, or maybe restructured text, or but if you were unconcerned about markup, you'd just use plain-text, without markdown. I didn't say unconcerned - markup conveys meaning as much as the words but needs to be secondary to readability if reading the source text is important. If reading the source isn't important then it doesn't matter if the markup gets in the way. Which is one of the goals of zml but not markdown. ok... then again, i was _talking_ about z.m.l., and the general issue of auto-assigning an i.d., as well as markdown-extra and multimarkdown, and pandoc too, in terms of that general issue, one that's ignored completely in gruber's version. all in all, i think it was an encompassing overview, one doing justice to the issue and its complications. different use-cases are gonna have differing values, but that's a good thing because it broadens our view. I don't really see an advantage to unique headers did you look at the examples i gave, from the manual for multimarkdown? i think the case is fairly obvious. i think for any specific instances you examine, you'll find it often helps to go unique, rarely (if ever) hurts. i'd say i see non-advantages to non-unique headers... Maybe my needs are too simple. That's something that can be handled as a post-process in my workflow, there is no post-process. and still, why put off until post-process what you can do now? Why think about it so much if a post-process can do it for you? And generally, where markdown is used a post-process is available. Anyway, we seem to have gotten off-topic here which was, I believe, concerning which markdown extension version you shoud be concentrating on for a conversion process from z.m.l. And i think that depends entirely on your intentions forthe converted text. If you are seeking general markdown-compatibility you need to stick to the base Gruber perl version, which is in general followed by all the offshoots. If you are aiming at a specific offshoot then there's your answer (pandoc, multimarkdown, what have you). I got distracted with all the multiple blank lines whoa! seumus! you got distracted by blank lines? that's getting tripped by the absence of your shadow! you are obviously more zen than i am... :+) What is the sound of one bracket clapping? I agree that too much markup gums up the editing - and especially the composing. Less is more. right. writing and rewriting. that's what editing is, to me... everything that happens from blank page to polished product. and angle-brackets are a terrible distraction. In general light markup is cool because it allows cool writing and editing without using html for those who can't be bothered. this is where we agree, yes. .html is tedium that can be auto-applied after the editing. (or any midpoint within the process of doing the editing.) It's not why I use markdown and I don't really care if it's cool or not. I don't have a blog that I use a light markup for. I don't have a public website that I keep updated using a light markup for content. I just organize my own personal offline information using it. interesting. i don't think that you are the typical use-case, but i would love to hear exactly how your system works and how markdown adds value to what sounds like a text-base. Well, I use headers a lot to separate sections of data. Usually just Header1 === and Header2 --- which allows me to easily locate the sections in the text. The other styles of header do not stand out so much as these and I tend to avoid. I also use lists a lot for outlining, sometimes up to 3 or 4 deep. Mostly unordered but occasionally ordered if making note of a process for my reference and listing the steps to take. I also usually ensure that they all line up neatly to distinguish the levels clearly (kinda ocd maybe). I add links (which are, naturally, only useful in the rendered version) to create a hyperlinked mess out of it all, kinda like a mind map. If I know what I'm looking for I just open the source from a file browser (like looking up a favourite recipe or recalling a computer admin task process steps), if not I boot up the web browser and peruse the rendered version following the links to find what I want. I also cut and paste a lot, for which markdown is passable - there is always some cleanup required if it's to be rendered ok. Lists copy fine, songs and poetry not so much. It's a hybrid text-based hyperlinked-based mind dump system. I also can add references to online info and images as required (for instance sample weld symbols for drawings - I have a lot of reference material in this for my job). They of course, like the links, work better in the rendered version. It works for me, probably not for anyone else. And I have found that
Re: markdown conversions
On 06/25/2011 03:10 PM, bowerb...@aol.com wrote: richard said: This seems like a bad idea to me. it still seems like a great idea to me, richard... ;+) Well, it was your idea :b (i'm responding just for the sake of discussion, not because i consider any of this to be vital. so understand that this is all very lighthearted.) Same reason I'm responding in the mission of Markdown i was talking about my own system, which doesn't give a stinky fart about the mission of markdown, thank you. :+) that the content comes first and it should never be dictated or impacted by the markup. except the markup is the whole purpose of markdown. how can the purpose and the mission be inconsistent? (that's a rhetorical question. just for the discussion.) Umm, no. The purpose of markdown is intuitive markup that does not get in the way when you write but still allows simple html elements to be added to enhance the text. If we were only worried about markup we'd just use html, or maybe restuctured text, or (if truly masochistic) docbook. Or wikitext with '5 single quotes all over the place' Requiring unique headers is much more intrusive than somewhat ugly markup. maybe, but the unique headers allow anyone at all -- even someone looking at a printout -- to know what the unique i.d. for a given header _will_ be... with certainty. i think that's worth it. besides, forcing headers to be unique gives the reader better navigational aid when they're inside the e-book. (and remember that e-books are the focus of my work.) a repeated header just causes confusion about location. it's better to elaborate on the header so it gets specific. so, in the long run, this isn't just about links at all... it's about making a book with a transparent structure. Which is one of the goals of zml but not markdown. I don't really see an advantage to unique headers myself. That's something that can be handled as a post-process for generating tables of content or whatever. Markdown extra makes a common mistake among extensions - it sacrifices readability of the plain text to ensure a unique element and simplify parsing. it's clear that duplicated text in the file just junks it up. so, in the abstract, i agree... plus z.m.l.'s readability is far better than markdown's. Personally I got distracted with all the multiple blank lines so I'd have to disagree there. but, again for discussion, i say readability of the plain text is highly over-rated. simply because nobody's gonna read the markdown file. I do all the time, that's why I use markdown. Probably the main reason. the only reason you added the markdown cruft is so that the content can be turned into .html. so read that .html. why should the reader imagine big bold headers when s/he can view rendered headers that _are_ big and bold? Not the ONLY reason, no. It also provides visual clues to the source when read. I can easily distinguish headers and lists in the source text. If I was only reading the rendered pages I wouldn't be so worried about the readability of the source. the reason light-markup is cool is not better readability, but better _edit-ability_. markup of any kind is obtrusive. and intrusive. it's an obstacle, one that gums up editing. put the focus where it belongs -- on editing, not reading. I agree that too much markup gums up the editing - and especially the composing. Less is more. In general light markup is cool because it allows cool writing and editing without using html for those who can't be bothered. It's not why I use markdown and I don't really care if it's cool or not. I don't have a blog that I use a light markup for. I don't have a public website that I keep updated using a light markup for content. I just organize my own personal offline information using it. And in general, except for tables I find vanilla markdown just right. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: markdown conversions
On 06/23/2011 05:29 PM, bowerb...@aol.com wrote:
alan said:
I think I am in agreement,
if by isn't necessary you mean to say that
simply providing more features to Markdown
doesn't force end users to use them,
or even really know they exist.
except that wasn't what i meant.
i mean that it's not necessary to trade simplicity
in order to get the power of additional features...
indeed, i believe that -- in the purview of a system
whose chief asset is its simplicity -- that would be
a bad trade. and, as i've read gruber, so would he;
he is an admirer of the grace apple brings to bear.
I know I am firmly on the side of this stuff --
footnotes, DLLs, fenced code, attributes on headers,
automatic TOC -- is useful, and sensibly implemented
in the Markdown plain-text spirit, and thus good, myself.
i am all in favor of all of those more-powerful features.
i just don't believe it's necessary to give up _simplicity_
in order to get them. you might have to sacrifice some
_customizability_, but that's an acceptable trade, for me.
at one point, i was ready to discuss a range of stuff that
could reduce the complexity of markdown variants, but
nobody else seemed interested in having that discussion.
so the moment passed. and i'm not inclined to do it now.
but, just as one for-instance, markdown extra lets you
assign an i.d. attribute to a header, by adding it like this:
## Header 2 ##{#header2}
the extra power that this gives users is undeniable, and
much-needed. but that convention is just an ugly hack.
it's extra work, and it's error-prone, plus it looks awful.
why wouldn't/shouldn't an i.d. be assigned automatically?
so other variants, such as multimarkdown, do just that.
but, even in its own user-manual, it gets itself confused,
with multiple headers being auto-assigned the same i.d.:
id=advanced
id=basic
id=bibtex
id=compiling
id=footnotes
id=images
id=rawhtml
pandoc checks for such duplicates, and appends a suffix
(-1, -2, etc.) to assure that each one has a unique value...
that's an ok solution, except that it makes it difficult to
know what the i.d. is for any specific header because you
have no idea whether it required an appendage, or not...
i myself, with z.m.l., simply require that each header be
unique to begin with, thus avoiding that potential glitch.
and i assign an i.d. to each paragraph, because... why not?
that's how you give the user more power _without_ adding
more complexity. (or gumming up the file with any crap.)
-bowerbird
Fascinating --- I read this list and I see feature requests and
discussions going nowhere because nobody gets beyond the fact the bdfl
of markdown has gone awol. Thus the base markdown is Gruber's perl
markdown implementation. Anything that others add are above and beyond
the base (even if they fix edge cases). Thus markdown-_extra_ for tables
and such.
Yet here we are discussing a zen-to-markdown converter and want to know
which above and beyond version it should adhere to. Sorry but, in
light of the very real inability of anyone else to take over as bdfl and
point the way, if you want to convert to markdown you currently need to
use the base perl markdown as the reference. Otherwise you're converting
to a superset of markdown.
You could create a converter zml-to-pandoc, or zml-to-multimarkdown, but
they won't be zml-to-markdown. And really, the choice depends on your
target audience and what they are going to do with it.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Data loss issue: Adjacent List Types
On 06/06/11 02:26 PM, Alan Hogan wrote: Quoth _Lasar: while I agree that this is technically an issue, I don't think it is an often seen issue in actual human-written text. Markdown is plain text formatted by and for humans. I don't think there are many cases where you would want to put two lists after each other without an introduction of sorts. I must of course agree that it is not an exceedingly common case, or a terribly sensible decision to make. That said: * Consider a student quickly taking notes, or a liveblogger publishing quickly. They may not have time to write an intro for each list, or realize that they skipped it… * I personally have experienced this issue, so it does happen. * Even if a small fraction of users run into this issue — half a percent, say — if I am providing a service to two hundred thousand of users (and I do), that’s a thousand people affected. I have also come across this on occasion (certainly enough to be annoyed by it). I solve by adding an extra blank line but always after the fact as never remember this when writing. And on a side note: Gruber notes in the markdown spec that the actual numbers used in a numbered list are ignored. So data loss is already occuring here. Now that is true. However: * Existing data loss doesn’t mean we should be okay with more data loss. * The numbers couldn’t really be always matched in output given how HTML works, anyway… * I personally made a mistake by starting a paragraph with “1999.” today, so this too can cause problems. (At least it’s part of the Markdown spec though.) * I am personally disappointed that the `start` attribute (?) isn’t used, based off the first number in the list; this would also help catch mistakes. Given that I still struggle to see a downside to making my proposed change, I’m really hoping we can achieve a rough consensus here. The data loss is only the list numbers, NOT the entire ordered list structure itself. It is not so much data loss as data replacement. The expectation is that no matter what number you use to start your ordered list it will when rendered start with 1. Therefore, mark me as +1 for this as well. I also remember copy-pasting some info from the web that had a sentence starting with 1999. (or similar) as there was a hard return in the line before it. It took me ages to figure out where that list was coming from in the middle of the paragraph. Eventually found the hard return and deleted it. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
I thought the topic was a proposed table specification? Like it says in the subject line? Somehow it ALL got off-topic. On 05/20/2011 04:05 AM, Christian Sciberras wrote: Yeah, let's all get back on topic, 'coz bowerbird said so. What was the topic again? Oh, trolling on how everyone want to make his own personal markdown spec. I've nothing to add than that it's their own decision. Chris. On Fri, May 20, 2011 at 9:56 AM, bowerb...@aol.com mailto:bowerb...@aol.com wrote: i said: if anyone wants to get back on-topic, i'm game. and now i add that if your posts are not on-topic (i'm looking at you, christian), i am _not_ game... so don't bother trying to play me. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto: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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: An Observation
I was commenting on the Gruber comment, not making a real-world observation. I have used a few different implementations and the results are consistent except for the edge cases. However, there ARE edge cases where results are not consistent with common expectations (typically from users who do understand the rules), and are indeed discussed in great detail on this list. Most users here would prefer that the expectations took precedence. Gruber's comment indicates otherwise. The compalints about Mr Gruber seem to me to be more along the lines of users wanting extra features (like tables, footnotes, etc) or wanting edge cases made more consistent, with Mr Gruber being quite content with the status quo and not even bothering to comment on the feature requests or edge cases. Since he is deemed to be the BDFL of markdown nothing therefore changes. Implementers then have the conuntrum of either literally following what Gruber's markdown does or following what common expecations want. Added features become individual enhancements with no central authority. In essence, each implementation becomes a fork of markdown. Forks tend to diverge, making interoperability problematic. Personally, I am quite content with the current feature set of markdown, which probably explains why I have a very low posting rate here. I don't use tables or footnotes very often so I don't miss them but I can understand the need for them. On 16/05/11 11:16 PM, David Parsons wrote: On May 16, 2011, at 7:42 PM, Seumas Mac Uilleachan wrote: On 16/05/11 10:18 PM, Dr. Drang wrote: A bit of Kremlinology: [...] lol A) The rules produce inconsistent results. In rare edge conditions, yes. But the operative word here is *rare*; if they happened all the time, people would be screaming much more loudly that they are now (and, really, it seems that a lot of the complaints about Mr. Gruber not continually futzing with the language is coming from the obnoxious open source belief that if people aren't continually tweaking the code it's dead.) As an implementer, I'm *very* happy that the language has become stable; this means I get to spend my coding time fixing bugs instead of chasing the latest I got bored, so I rewrote everything release. (something I can't say for some of the extensions I try to support, which have silently morphed since I copied them.) -david parsons ___ 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: Proposed table specification (long!)
On 15/05/11 01:17 PM, bowerb...@aol.com wrote: simon- i'm not sure persistence will do you much good. nobody seems to have a desire to work together. which is likely why there are 39 implementations. Isn't the existence of 39 implementations due to each implementer having their own favourite programming/scripting lamguage? And don't most (if not all) strive to follow the canonical Gruber perl markdown implementation? The inability to work together as you put it is due more th the percieved apathy of the originators of markdown in the last few years and the lack of an appointed/accepted successor. an appeal on behalf of readers seems misguided, since very few people are reading markdown text. In my case I use markdown for a personal info management system and I read the text as often as the rendered html. But then it is my own text and I already know how I intended it to be interpreted. but a more potent case can be made for _re-use_. the more easily content can be remixed, the better. for my contender in the light-markup derby -- zen markup language (zml) -- to facilitate re-use, my goal is that users can round-trip the text... so if they copy the text out of the .pdf and use it to create _another_ .pdf, the two will be identical. likewise, if they copy the text from a web-browser, it will match the .zml file which created that .html. or copy the text out of one version (.html or .pdf) and use it to create the other version, just like that. i am coming very close in both cases. it'll certainly be the case that some global changes will always be required to restore the original .zml, but if i get it down to just a few, that will be an accomplishment. -bowerbird ___ 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: An Observation
On 16/05/11 10:18 PM, Dr. Drang wrote: A bit of Kremlinology: About a month ago, I tweeted that I was still hoping—perhaps in vain—for some sign from inscrutable Mr. Gruber. https://twitter.com/#!/drdrang/status/56175149489205248 He replied with this https://twitter.com/#!/gruber/status/56399420446609408 -- Dr. Drang ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss lol A) The rules produce inconsistent results. B) That's because you don't understand the rules. A) But when I apply the rules in certain cases I get nonsensical results. B) That's because you don't understand how to apply the rules. When you become one with the rules there is no inconsistency. When all the world knows _emphasis_ as _emphasis_, only then is there **bold**. ___ 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 05/06/2011 06:00 PM, Aristotle Pagaltzis wrote: * Waylan Limberg way...@gmail.com [2011-05-05 03:25]: However, most projects I'm aware of use '.md' or '.markdown'. `.mkd` and `.mkdn` are also popular. I’ve seen `.mdwn` also, and I think even `.mdn` though I’m not sure about that one. Regards, I also recall seeing .mdown somewhere. I think the point is that the extension really shoudn't matter. Use what you want. Let the metadata take care of the rest. Similar to a #! in shell scripts to specify language interpreter. Don't matter what the extension is there either. I have also over the years seen .txt, .text, .doc, .note, .asc, .ascii, and no extension at all for text files. Also read.me ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On 25/03/10 10:08 AM, Aristotle Pagaltzis wrote: * Seumas Mac Uilleachanseu...@idirect.ca [2010-03-24 01:30]: Elastic tabstops would certainly make my pseudo-table much cleaner. Would make creating such a table a breeze without requiring special markup. Is this idea actually catching on Yeah, elastic tabstops solve this problem in a fundamental way. The problem is they’re a boil-the-ocean solution, they require support in almost all tools that will touch the document in question. That’s a very high activation energy barrier… you’ll need a catalyst to get them adopted, eg. a new OS/platform that fully supports them from the get-go – essentially you need an Apple to throw their weight behind it. like Sony Beta - a better solution that no one will buy into? Myth. Betamax was inferior to VHS in significant ways, even if it had an obvious advantage in picture quality and cassette size. The market decided that people prefer VHS’ mix of good and bad to Betamax’ mix of good and bad. End of story. It’s like saying webmail is inferior to desktop mail clients. Regards, Beta was inferior to VHS in market penetration because VHS was licensed for free and Beta wasn't. Much like the PC vs Mac early on. In both cases the Beta and Mac were technologically superior but cost more. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On 24/03/10 01:49 PM, bowerb...@aol.com wrote: sherwood said: I don't understand. what's to understand? :+) Are you saying that MD should recognize elastic tab stops in a file and convert that to a html table? yes, that's what i'm saying, or at least part of it. This is certainly a possible route, but given the number of editors that don't recognize elastic tab stops, this is daunting. at some point, you have to free yourself from the constraints that low-quality software imposes on your workflow, yes sir... but, you know, all it takes is for one brave leader to _lead_, and a number of non-cowardly followers to _follow_, and -- before you know it -- a new capability is taken for granted. It also means that MD needs to recognize at least two ways to do tables -- ets and markup. well, if you want to keep a horse around in addition to your new horseless carriage, by all means, feel free... ;+) Are you saying that browsers should all be smart enough to recognize elastic tab stops? yes. every text-editing environment should have the capability. because -- if you've programmed it, like i have -- you'll know that it's really not all that difficult to code. indeed, it's easy... and although i don't remember this in the work-up on them (because i conceived them long before that, independently), this functionality should include a feature that will convert multiple spaces to a tab character (the easy part) as well as convert a tab to the correct number of multiple spaces... (e.g., so the table displays correctly in a monospaced font). i'd think the default save-format would be multiple-spaces, just to accommodate the non-tab-aware software out there. there's nothing magical about this functionality. it's just a straightforward implementation of old-fashioned tabs, with the new wrinkle that the columns are self-adjusting to the size they need to be. which is something we could have reasonably expected our computers to do all along... (indeed, isn't this capability already in most spreadsheets?) While an admirable goal, I won't hold my breath for the day that 95% of browsing is done with ETS capable browsers. i'm not holding my breath for 95% of browsers being _capable_, in _any_ sense of the word, not as long as we have a microsoft... but in cost-benefit terms, cost being low, benefits being high, this particular feature is one that has a good cost-benefit ratio. all it will take is for somebody out front to just do it... this is _not_ a betamax/vhs situation. vhs was good enough. nobody says our current table functionality is good enough. -bowerbird You're not really talking tables here though, you're talking self-aligning columns of text. That is not the same thing as an html table, even though that is what tables are often used for. ___ 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: Markdown development
On 24/03/10 02:20 PM, Sherwood Botsford wrote: Given the paucity of ETS editors, viewers, enabled browsers however, I'm afraid that I will insist on keeping my horse, at least until there is more than two roads in town. My horse will eat hay. And who knows where the next gas station is. The bowerbird is half right. Elastic tab stops are worthy of implementing. But to keep the transition cost minimal the older way has to be supported also. I can see merit in having MD understand elastic tab stops as part of it's goal toward minimalist markup. It certainly would make simple tables easy to do. Respectfully, Sherwood of Sherwood's Forests Sherwood Botsford Sherwood's Forests -- http://Sherwoods-Forests.com 780-848-2548 50042 Range Rd 31 Warburg, Alberta T0C 2T0 If I understand the concept correctly, Markdown wouldn't really have to know anything about ets. Their implementation would be up to the browser-editor-ide-etc. All MD would have to worry about is tabs. If there's a tab in the middle of three lines of text, adjust the text after each tab to line up. If there's a tab in front of three lines of text line up the three lines. If there's two tabs, indent it more. The actual lining up is not MD's problem. Currently MD has the tab at the beginning of the line stuff. A tab in the middle of a line shouldn't affect MD at all, should it? The actual implementation would depend on whether the font was monospaced or proportional, again something MD doesn't care about. On Wed, Mar 24, 2010 at 12:11 PM, david parsons o...@pell.chi.il.us mailto:o...@pell.chi.il.us wrote: In article 1ffdc.6466484d.38dba...@aol.com mailto:1ffdc.6466484d.38dba...@aol.com, markdown-discuss@six.pairlist.net mailto:markdown-discuss@six.pairlist.net wrote: --===1294852797== Content-Type: multipart/alternative; boundary=part1_1ffdc.6466484d.38dbaac4_boundary --part1_1ffdc.6466484d.38dbaac4_boundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit sherwood said: I don't understand. what's to understand? :+) Are you saying that MD should recognize elastic tab stops in a file and convert that to a html table? yes, that's what i'm saying, or at least part of it. And this would convert markdown from a general-purpose writers tool into some sort of boutique plugin. I can't really see that this would count as an advantage to _anyone_ who currently uses markdown. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto: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 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On 23/03/10 02:11 AM, Albert Skye wrote: It depends on what you are trying to do. If you want a simple multi-column list of corresponding text such as: Position Team P GD PTS 1 Man Utd 31 46 67 2 Arsenal 31 40 67 3 Chelsea 29 42 64 4 Tottenham 30 26 55 5 Liverpool 31 19 52 6 Man City28 17 50 7 Aston Villa 29 17 50 8 Everton 30 6 45 9 Birmingham 30 -3 44 10 Fulham 29 0 38 11 Stoke 30 -6 36 12 Sunderland30 -6 34 13 Blackburn 29 -17 34 14 Bolton 31 -20 32 15 Wigan 31 -30 31 16 Wolves30 -24 28 17 West Ham 30 -14 27 18 Burnley 31 -33 24 19 Hull 30 -35 24 20 Portsmouth30 -25 13 FWIW, that's pretty illegible at whatever tab width my MUA uses. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss FWIW it isn't an html-formatted table. I just copied it from a football website. It doesn't look very nice in mine either. The spacings got all messed up in copying but I wasn't going to take the time to fix it. It's certainly legible in Georgia. And another problem is fixed vs variable fonts. I tend to use a variable font in my MUA (and elsewhere). That makes aligning text with tabs virtually impossible. Eventually, the character column will no longer be taken for granted. The sooner the better, for me. Syntax for tables (and anything else) which depends on fixed-width font formatting seems innately brittle and shorter of life than syntax which does not have that dependency. Elastic tabstops. http://nickgravgaard.com/elastictabstops/ Elastic tabstops would certainly make my pseudo-table much cleaner. Would make creating such a table a breeze without requiring special markup. Is this idea actually catching on or is it like Sony Beta - a better solution that no one will buy into? ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On 21/03/10 08:28 PM, David E. Wheeler wrote: On Mar 21, 2010, at 11:03 AM, Seumas Mac Uilleachan wrote: It depends on what you are trying to do. If you want a simple multi-column list of corresponding text such as: Position Team P GD PTS 1 Man Utd 31 46 67 2 Arsenal 31 40 67 3 Chelsea 29 42 64 4 Tottenham 30 26 55 5 Liverpool 31 19 52 6 Man City28 17 50 7 Aston Villa 29 17 50 8 Everton 30 6 45 9 Birmingham 30 -3 44 10 Fulham 29 0 38 11 Stoke 30 -6 36 12 Sunderland30 -6 34 13 Blackburn 29 -17 34 14 Bolton 31 -20 32 15 Wigan 31 -30 31 16 Wolves30 -24 28 17 West Ham 30 -14 27 18 Burnley 31 -33 24 19 Hull 30 -35 24 20 Portsmouth30 -25 13 FWIW, that's pretty illegible at whatever tab width my MUA uses. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss FWIW it isn't an html-formatted table. I just copied it from a football website. It doesn't look very nice in mine either. The spacings got all messed up in copying but I wasn't going to take the time to fix it. The point was that this is a commonly-used table type that there should be some standard mechanism for Markdown to deal with (and make it legible). There is such a mechanism in PHP Markdown Extra. There is in Multimarkdown (similar but different). There probably are in others as well (again similar but different). In vanilla Markdown there's html. Html as plain text is pretty illegible, much more so than this quick mashup table above. And another problem is fixed vs variable fonts. I tend to use a variable font in my MUA (and elsewhere). That makes aligning text with tabs virtually impossible. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On 20/03/10 04:02 PM, Aristotle Pagaltzis wrote: * Lou Quilliopub...@quillio.com [2010-03-20 00:55]: Markdown's dead? Absurd. Obviously. That’s why no one said that. Markdown *development* is dead. (Straw men are easy to clobber.) Markdown's huge, and in the form of PHP Markdown Extra is basically done. Done != dead, done == problem solved. Fact: the latest Gruber release is a beta. And has been for how many years now? The original markdown has not changed in years. That may be a good thing if it is stable, has no bugs or edge cases, does exactly what it advertises every time, etc etc. But it does not, witness the constant threads on this mailing list about edge cases, missing features, etc etc. Which leads me at least to presume that it is an orphaned software. It would certainly not be alone. I hear constantly about needing Gruber's blessing for any overhaul or changes to Markdown. Why? It seems obvious to me that he has lost interest in further development. Markdown was developed to meet a requirement he had and I guess the current state is good enough for him. That is absolutely fine and I have no problem with that. If it isn't good enough for everyone else (or at least those who are active on this list) then carry on with development, call it MD2.0 or Webtext Lite or whatever you like and just run with it. Fact: the latest official Gruber release is missing features that Gruber himself uses. You can argue about whether this means “done” – I see “scratches my itch so I lost interest” –, but you cannot argue the facts. Personally I think Markdown is still missing a lot of fit and polish that could make it much (subtly) nicer still. (Eg. I’m tired of using `!-- --` lines as a crutch to force consecutive, separate blockquotes and lists to be recognised as such.) What it’s not missing is big constructs. (I believe tables and definition lists can only be done badly, and so should not be done at all.) The goal of markdown is readability. There is no such thing as a readable html table. I would argue that tables are a useful enough feature to include. Whether it is done badly or well is often subjective. At the minimum a simple table format would be important to me (not requiring spanning cells or complex table layouts). Tables are the easiest way to list corresponding values or data that they really should be somehow included. I do like the way PHP Markdown Extra does tables. Unfortunately I don't use PHP anymore. Regards, ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: md2html.awk and a question
Hi, if I read your example right, the bullet markup should take priority over anything else in that line. So the #h1 ##h2 ###h3 etc should not be headers since they are part of a bulleted list. Also the # is not the first character of the line. As for the indented #an h1, should that be a header? I would think not myself. If it's indented it's intended to be something else to my thinking. As for the - btw, this an h1, not a list item === that is so ambiguous it could be either. I suppose the and headers, since they span multiple lines, probably take priority over everything. Then again, it may depend on your markdown version (perl, php, python, haskell, etc). yy wrote: Hello, I have just subscribed to this list. I will introduce myself: For some time, I have kept a markdown implementation in awk for personal use, different from other implementations. Now, I'm in the process of rewriting it and I'm trying to do it as compatible as possible. There are many questions I have, I know some test suites and am trying to pass those tests. When I don't know how to handle a corner case I use to check with Dingus. I would really appreciate if somebody could explain me the output of this text: this paragraph is outside of list blocks * #this is not a h1 * ##this is not a h2 * ###and this is not a h3 * but the next one is #an h1! inside a list item, ok, but... * ###wtf is this? bad, bad, bad... - btw, this an h1, not a list item === - but indenting... that's better I would also like to know what is the best source for markdown syntax, any suggestion is welcomed. For example, I see some talk about tables (older versions of md2html.awk supported tables, and I hope to add them again). I'm slowly digging in the archives, but a reference would save me some time. Thanks in advance. If you are interested, you can have a look at the development process of md2html.awk and download the last version at http://www.anarchyinthetubes.com/src/md2html.awk/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Desktop app for viewing Markdown files
Is there anything like that available for other OS'es (Linux, *BSD)? Tom Humiston wrote: MarsEdit. It's for writing blog posts. One can enter text in Markdown format and see a live preview in another panel, showing how it will look in a browser. Even if you don't actually publish to a blog. From the [vendor's website][1]: Perfect Previews Build a template to match your blog, then let MarsEdit's live preview show you how your posts will look before you publish them. Use Your Favorite Editor Combine the power of MarsEdit with your favorite editor. Integrates cleanly with BBEdit, SubEthaEdit, TextMate, or TextWrangler. Nearly every word I write for Daring Fireball is published through MarsEdit. -- John Gruber, Daring Fireball Tom Humiston Website Designer Psychic Healer Kalamazoo, Michigan, USA [1]: http://www.red-sweater.com/marsedit/ On 26 Feb 2009, at 9:35 AM, Jan Erik Moström wrote: Is there a file/document browser that render and display Markdown files? (for the Mac) jem ___ 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: A Modest Definition List Proposal (David E. Wheeler)
David E. Wheeler wrote: On Feb 25, 2009, at 6:57 AM, Sherwood Botsford wrote: One minor change. You don't need pipes in the horizontal separator lines. E.g: id | name | description | more info They could be optional; I prefer them. 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? I think the only time I actually use monospace fonts is with Alt-F1 (or Ctrl-Alt) Admittedly it is easier to create legible text documents with lots of bullets and tables and definition lists if you are using a monospace font but in my experience monospace fonts are generally just harder to read. The beauty of markdown is that you can approximate the spacing of monospace by varying the whitespace. Or just let it be wonky. (Of course what looks beautiful in one proportional font will be wonky in another anyway) Add to this, the need for centering, the need for column spans. Allignment could be done with your horizontal separators. |---| Means use your default alignment. (Same as cell above) || Means left alignment. The can appear anywhere between the |'s |--| Means right alignment. |-=| means center alignment. I dislike these. I have other ideas for alignment, but I need to do some more thinking and drafting before I have a proposal to submit. Column spans could be done by replacing the pipe with an underscore. |=_===| |This is a cell that spans two| columns, and is centred. |--|--| |Column 1 |Column 2| I'm working in a proportional font, so the above example is sure to be wonky. Yes, and basically illegible. Note that these two ideas are contradictory. To merge, them (makes reading slightly harder, but writing slightly easier. | Default alignment | | Left Alignment | | Right Alignment | |= Centered alignment =| The alignment tags don't have to be paired, but can be for eye candy purposes. || Spans two columns of the stuff below | | Column 1 | Column 1 | IMHO, any formatting should be invisible in Markdown. That is, it should be implicit. The use of all these extra characters to show alignment and whatnot makes for ugly text-only tables. Best, David ___ 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: forking Markdown.pl?
LOL that was actually funny :) (No the number is still 42) Seriously, it is easy to get up in arms when your creation ends up becoming bastardised, whatever the form that may take (for better or for worse). To be honest, I have not really seen for myself that MultiMarkdown has a whole lot to offer, but that's just my opinion. Of course perl tends to give me a headache so I really can't be all that objective (I really tend to understand PHP better). I really like the fundamentals of Markdown, that what you type is basically what you will more or less see in a browser viewing the text... However, if you (JG) are willing to let this beautiful creation of yours stagnate, then you should not take offense when others take up the plate (however tarnished) and take a couple baby steps forward... Joseph Lorenzo Hall wrote: On Sat, Mar 15, 2008 at 7:25 PM, Joseph Lorenzo Hall [EMAIL PROTECTED] wrote: good stuff... gruber's an asshole, as far as I can tell. best, Joe Damn. Well, I didn't intend for that to go out to the entire list. I apologize, but I also found the recent response to be harsh. I'll be more careful with my `To:` lines in the future. best, Joe ___ 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: on the philosophical aspects of a specification
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 Really. Regards, See, now that's not at all what I inferred from this case. If we infer different meanings here then there are undoubtedly many cases we can't even think of that would be inferred differently. How is the spec supposed to handle all this? Admittedly we can just go back and make changes if the result doesn't match our expectations but which was the real error in that case? The result or the expectation? BTW I inferred emhello strongdear/em boy/strong which maybe for strict XHTML should be emhello strongdear/strong/emstrong boy/strong ___ 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
Waylan Limberg wrote: 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! Many users (especially where markdown is being used as a plugin for a blogsite etc) will not even be aware of valid/invalid markup and closing tags properly or not. Turning *hello **dear* boy** into emhello strongdear/strong boy/em makes assumptions about the trailing asterisks and errors in formatting that are possibly different from the user's intent (like mixing up ** and * to close the tags), and implies an error-checking mechanism built into markdown to catch such cases. Maybe what is needed is some kind of syntax checker to run the source through to point out to users where there are errors and/or confusing markup. This could be a separate function from markdown itself, like markdown-lint, or a separate output option of markdown. A separate function would keep the markdown parser smaller. A syntax checker would also help users identify what the problem is when they get unexpected results. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: on the philosophical aspects of a specification
Michel Fortin wrote: Le 2008-03-04 à 21:47, Seumas Mac Uilleachan a écrit : david parsons wrote: And how about _cut here_ ? This is a problem. Anything more than 4 _ per side does not render but with 4 it does (in PHP) if you have cut here are you expecting it to be converted to emstrongemcut here/em/strong/em ? Well, that's already much better than what you get from Markdown.pl. :-) But I agree it could still benefit from some improvement. [...] And speaking of ambiguous * List * List * List * List * List * List * List * List Yeah, the list implementation in Markdown.pl and PHP Markdown doesn't follow the at all the little of a spec we have now. I've been thinking about rewriting the list parser in PHP Markdown, but I'm wondering what to do to not suddenly change a myriad of documents which may depends on some part of this behaviour, such as: * item * subitem * subitem * item * subitem (Here, no item is indented by four space, should this be a flat list?) We have to decide what the intent is - if indents are two spaces or more that indicates sublists, where one space indicates a mistake in typing? What if the mistake results in your sublist item becoming an upper list item (space one instead of two)? Lists in general need to be more precisely defined. I for one would like to see the ability for arbitrary starting points in numbered lists added. Then again, how many existing documents will that break? I know people have written lists like the above in their document. They did it because it produce what they expect in their Markdown implementation, because the thing is readable and make sense, and because didn't bother to read the spec. What was the intent here? I would suggest more like * List * List * List o List * List * List * List o List Since only the 4th and 8th are indented 4 spaces. Eh, I don't see a four space indent anywhere in your example. But, assuming your output got screwed up while editing and that the last list element belongs on a separate line, I agree with you that it's probably the best possible output to represent the author's intent. Um, looks like first space got chopped off all the lines. Indents were 3,2,3,4,3,2,3,4. I was trying to show what happens if you aren't exactly precise on your spacing. I personally always start my lists with zero spaces when typing but when cutting and pasting lists I can end up with 1,2,3, as much as six spaces in front (obviously with six I do need to revise but otherwise I just leave as is). If someone habitually uses two but at one point mistakenly types one or three instead - the intent was two but how should Markdown handle that? Currently (which is strange) the first line in my example has three spaces and is a first level list. The next line has only two but becomes a **second level** list. Michel Fortin [EMAIL PROTECTED] http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: on the philosophical aspects of a specification
david parsons wrote: In article [EMAIL PROTECTED], Seumas Mac Uilleachan markdown-discuss@six.pairlist.net wrote: david parsons wrote: In article [EMAIL PROTECTED], markdown-discuss@six.pairlist.net wrote: however, implementers can reach agreement easily, by leaving users out in the cold, brushing them off with a you will need to follow the spec which seems -- if i understand markdown's cornerstone correctly -- to be outside gruber's comfort range for his creation... If a user says I want paragraphs to start with an explicit paragraph symbol and all newlines to force a br/ , I *will* brush them off with a you will need to follow the spec because that's not how Markdown works.I can't imagine any other way to actually write the language. [...] What we care about is that the original intent of our written source is maintained. I'm not surprised when 1986. What a great season. generates a list item, because the existing spec tells me that ``[...]a _number-period-space_ sequence at the beginning of a line[...]'' will trigger an ordered list. But what's the intent of ***hello*, sailor** ? The stated spec says text wrapped in one * is emphasis, two ** is strong. Should it produce 1. strongemhello/em, sailor/strong 2. strong*hello*, sailor/strong 3. *stronghello*, sailor/strong 4. ***helloem, sailorstrong 5. ***hello*, sailor** 6. emstronghello/strong/emstrong, sailor/strong 7. emstronghello/em, sailor/strong (which makes baby XML cry) ? Item 4 only makes sense if the source is taken out of context (a snippet), and then how do we know? Items 2-5 all assume some *'s are literal which doesn't follow the spec if the text is wrapped. Items 1,6, and 7 all render the same in the browser and the choice of which is up to the implementation (following the syntax spec). How about **Hello, sailor ? Is this a snippet? if not, then the text is not wrapped and the syntax does not apply. Is it strongHello, sailor, **Hello, sailor, or em/emHello, sailor? And how about _cut here_ ? This is a problem. Anything more than 4 _ per side does not render but with 4 it does (in PHP) if you have cut here are you expecting it to be converted to emstrongemcut here/em/strong/em ? Formal specifications are written to avoid surprises in the implementations;As a user (and there's no way I'd have written an implementation if I wasn't a user) of the language I'd like to avoid surprises when I go between the markdown documents on my website, posts on my weblog, or posts on someone else's wiki and/or weblog. I did not say that a formal spec was a bad idea. A formal **syntax** specification that is clear and unambiguous is where we need to start, without losing sight of the great usability that Markdown has right now. The biggest problem is that the syntax is ambiguous. The biggest strength is that the syntax is flexible (0,1,2 or three spaces at the start of a list). And speaking of ambiguous * List * List * List * List * List * List * List * List converts to: ul liList ul liList/li /ul/li liList ul liList/li /ul/li liList ul liList/li /ul/li liList ul liList/li /ul/li /ul which shows up as: * List o List * List o List * List o List * List o List What was the intent here? I would suggest more like * List * List * List o List * List * List * List o List Since only the 4th and 8th are indented 4 spaces. ___ 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)
Joseph Lorenzo Hall wrote: Sounds like there are quite a few people who write intuitively by placing a space or two before a list marker. Next question: what if we only allowed a fixed number of whitespaces before a list marker? For example, what if the spec said 0-1 whitespace characters before a list marker? Is that too rigid? This would accommodate those of us that write with a space before a list marker, but wouldn't capture my edge case (with the 2008. indented three spaces on a newline). best, Joe What's needed is a way to distinguish your edge case from the general case where it would be a list. Do you use two white spaces to preserve the line breaks? Perhaps that could be the trigger in this case - a line ending in two white spaces prevents the next line from being formatted as a new list. I just tested this edge case in PHP Markdown Extra and it does the same thing (both with and without the two white spaces for newlines). ___ 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?)
I wholeheartedly agree. The main attractions of Markdown to me are:
1. It is easy to read
I use Markdown for personal info and stuff, then convert and read in
a browser. But for me it is ALSO important to be able to easily read the
original source. That is where Markdown excels over the other
text-to-HTML conversion tools. I have tried other methods (generally
wiki's) but find their markups generally nonintuitive or hard to read in
source (especially the use of apostrophe 'ugh')
2. It is fault-tolerant
The rules are loose enough that if I don't use the exact number of
spaces I still get what I intended rather than what I actually entered.
Or if I add a space or two in front of the bullets (often by cutting and
pasting) it still works. Actually that is a good point too - cutting and
pasting with Markdown requires less after-the-fact cleanup than the
other systems I've tried.
We need to keep these point in mind when discussing the future of
Markdown. I do use PHP Markdown Extra, but ONLY for the tables feature
('cause HTML tables are tedious and I'm lazy). Other than that I stick
pretty much to the original and just use HTML if something extra is needed.
Less is more when it comes to Markdown's syntax. Markdown is intended to
make text writing easier and more legible than is currently possible
with HTML. The least (and most flexible) syntax rules required for that
should be the goal.
Waylan Limberg wrote:
With all this discussion about evolving the spec, I think we want to
remember the philosophy behind Markdown to begin with. Go re-read the
Overview[1] of the syntax rules.
[1]: http://daringfireball.net/projects/markdown/syntax#overview
As the very first line says:
Markdown is intended to be as easy-to-read and easy-to-write as is feasible.
Personally, some of the holes in the current syntax rules are
actually the features that makes this statement true. As
implementors, we want a strict spec because it's easier to implement,
but that does not always result in easier to read and/or write.
Take the discussion a short time ago on this list regarding whitespace
allowed at the start of a list item. A quick read of the rules would
indicate the the `*` or number should be the first item on that line.
In practice, markdown.pl allows up to 3 spaces at the start of a list
item. While J.G. agreed (IIRC) that that probably is a bug that should
be fixed, we learned through the course of that conversation that a
number of people actually are relying on that bug as a feature,
and in fact, if the bug was fixed, their documents would break.
Admittedly, why those three spaces were allowed to begin with is
beyond me, but when we consider the philosophy behind Markdown, we
realize that it is *easy* for a writer to inadvertently add a space to
the beginning of a line of text, but *hard* for that same writer (or
future editor) to find that space to remove it later. Therefore, as
crazy as is sounds, this bug is a feature when the philosophy is
taken into consideration. My guess is that this is also why J.G.
doesn't give a rip about a spec. A spec doesn't fit his
understanding of the philosophy behind Markdown (which he wrote).
Now, before you all write me off as insane, this is actually why I
think Markdown 2.0 is a good idea. By moving to 2.0, we don't have to
worry about backward compatibility (Markdown 2.0 should not allow
those 3 spaces). There have been various situations (some edge cases,
some not) that are not addressed in the current rules, and AFAIK those
rules have never been updated to address them. A new set of rules
would open the doors for all kinds of possibilities. However, in
writing those rules, I think we need to keep that philosophy at the
**forefront**.
For example, many people will propose various additional syntax to
accomplish different things. In general I would be opposed to nearly
every one when considering this excerpt from the current rules:
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.
That's not to say that there are no valid arguments to add additional
syntax, but the arguments for those new rules would need to be very
convincing. After all, that's what attracted me to Markdown in the
first place. I hate editing HTML. Don't get me wrong, I know my way
around an html document, but even standards compliant, well structured
html can start to look like tag-soup the more you stare at it. On the
other hand, I can send a Markdown document to someone that has never
seen html and they **should** be able to read and understand most, if
not all, of the markup immediately. Lets keep it that way!
If you notice, I never suggest that Markdown
Re: spelling with g?
Yuri Takhteyev wrote: I am with Waylan on this one. :) Our approach has been to give the user the choice of three options: we'll remove HTML-like tags, or escape them, or leave them. Trying to sort them into HTML and non-HTML tags would be too error-prone and limiting (for the reasons Waylan mentioned). That said, there is no reason why markdown libraries couldn't accept an explicit list of valid tags as a parameter: html = markdown.markdown(text, extensions, options, allowed_tags=['a', 'i', 'b', 'img']) I suppose we could even set a few constants for you, so you could do something like: html = markdown.markdown(text, extensions, options, allowed_tags=markdown.HTML5_TAGS) In general, perhaps we should think more in terms of what options markdown libraries should support rather than in terms of what Markdown does by default. - yuri In a not-exactly-related problem, I have been using a personal wiki to manage my personal info. I use PHP Markdown Extra (for the tables) for the markup. Part of that info is e-mail addresses. I paste the address and then surround with ... to make it a link. Unfortunately, if the e-mail address is [EMAIL PROTECTED], the link becomes a html hard return instead. If I add the mailto: in front then it becomes a link. Interestingly, if I look at the page source the hard return shows up as [EMAIL PROTECTED]. I would think that anything with an @ should be, if valid, converted to an e-mail address. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
