dean allen is gone
dean allen slipped the bonds last week. allen was one of the pioneers of light-markup, in the form of his 2002 entry "textile", which he billed as "a humane web-text generator" that would enable a person to "simply write". lots of people took part in the invention, yes, but if you had to point to one single individual, there's little argument that it'd be dean allen. (unless you would prefer to credit ian feldman, who invented "setext" in 1991 for "tidbits" and even argued for its use as the default markup for the thing that eventually became the web.) textile was used by the seminal "movable type". https://news.ycombinator.com/item?id=16183014 oh, and those who write for wikipedia?... you might wanna fix this little omission: https://en.wikipedia.org/wiki/Dean_Allen -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
an interesting throwaway line
gruber posted about markdown on his daringfireball blog, which is rare enough to be noticeable. but it became fully remarkable when its final sentence made a passing reference to a possible "update to markdown" event -- as if such a revision isn't a thing he's always steadfastly refused. this isn't a reading of tea-leaves. it is a sudden jarring appearance of tea-leaves in a place they have never ever appeared before now. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Feed.TXT - A Free Feeds Format in Plain Text w/ Structured Meta Data and Markdown ;-)
gerald said: > May I highlight the latest (and greatest) feed format aaron swartz in 2002 said: > http://www.aaronsw.com/2002/rss30 -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
beaker-browser supports light-markup sites
beaker-browser is an interesting experiment. and it's one of the pioneers of something that i suggested some time ago here, that the web should support light-markup in a native way, by allowing people to simply mount such files, which are then auto-converted by the browser. > https://beakerbrowser.com/docs/tutorials/create-a-markdown-site.html -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: markdown rules / recommendations
gerald said: > If you know another see what the brett terpstra says: > http://brettterpstra.com/2015/08/24/write-better-markdown/ -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: New Static Site Theme for World (Literature) Classics in Markdown e.g. A Tale of Two Cities, The Trial, etc.
gerald- congratulations on the new wrinkle... *** speaking of meet-ups > http://viennahtml.github.io congratulations to kramdown for being selected the github-approved converter. which means it'd sure be nice to have a javascript implementation of kramdown. because i can now say, unequivocally, that commonmark excels in this arena. the javascript converter is here: > https://github.com/jgm/commonmark.js demo: > http://zenmagiclove.com/simple/commonmark-moby.html i've shown conversion-time in the title-bar. when you can convert a file like moby dick (1.2 megs) in under a second, you've got awesome client-side power working for you. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
organizational bloat
you can pretty much tell how much organizational bloat a company has by the complexity of its url structure > > https://developer.apple.com/library/prerelease/mac/documentation/Xcode/Reference/xcode_markup_formatting_ref/index.html#//apple_ref/doc/uid/TP40016497 -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: markdown wiki for compiling documentation
alan said: > take a look at the much-respected Pandoc project. good suggestion. and along those lines, perhaps go all the way, and use a wiki app coded by pandoc's john macfarlane. > https://github.com/jgm/gitit a running demo, with a sandbox, is at: > http://gitit.johnmacfarlane.net -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
commonmark is used in the swift compiler
> https://swift.org/source-code/#cloned-repositories > The source code for CommonMark, > which is used in the Swift compiler. > https://github.com/apple/swift-cmark ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
crowd-sourcing for a new javascript browser-based prose editor
marijn haverbeke said: Sometimes I lie awake at night, feverishly searching for new ways to load myself down with more poorly-paying responsibilities. And then it comes to me: I should start another open-source project! http://marijnhaverbeke.nl/blog/prosemirror.html crowd-sourcing for a browser-based rich-text editor based on markdown and/or commonmark, whatever. one of marjin's earlier projects created _codemirror_, which is targeted at code. and he now attacks prose. he also wrote eloquent javascript, so he might be one of the best people to write this javascript code. more: http://marijnhaverbeke.nl/blog/collaborative-editing.html http://prosemirror.net -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: does fireball markdown support anchor links?
aristotle, your mockery entertains me immensely. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
markua -- a new flavor for long-form documents
some of you probably know that leanpub.com has been creating a new flavor targeted at books, which they are calling markua. their in-progress documentation: https://github.com/markuadoc/markua here's a little javascript thing to pull all of the chapters together: http://zenmagiclove.com/simple/do-markua.html that uses marky, brett terpstra's rad web-based converter, which in turn uses multimarkdown, so the resultant .html will _not_ be accurate according to markua... but it will give you a rough idea. http://markdownrules.com -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: does fireball markdown support anchor links?
david said: an option, though not a pretty one. it's ugly, yes, but that's not the worst part. the worst part is that it is a lot of work -- especially if you want a table of contents. and then it's obstacle-clutter while editing. it's really something that should be handled by the converter, not something in the text. which, by the way, many of the flavors _do_. but not to the extent that they could or should. in addition to headers, there should be anchors at significant places, such as tables and figures. and again, some flavors do indeed go that far... however there do remain coordination glitches, as different flavors create the anchors differently. some turn spaces to dashes, others to underbars, and some even delete them entirely, meaning that they didn't learn that old expertsexchange lesson. some use camel-case, others go all-lower-case... some include punctuation as-is, others delete it, and still others keep anything allowed in filenames (which varies across platforms, and on the web)... and of course there's the usual utf-8 complication. so, as is typical in this coordination-plagued sphere, users have to actually _look_at_ the anchors to see what they are, which defeats some of the purpose of auto-generating them in the first place. oh well... i'm not even going to suggest that the flavor-makers try to come to an agreement, because we all know that they aren't gonna change what they already do... -bowerbird p.s. i guess beamer has an appeal for some people, but reveal.js is so darn rad, especially its visual editor, that i would really recommend that you check it out... there are also other great web-based presentation-tools, but i can't get at the file with my notes on them right now. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
that's an endorsement
interesting to see asciidoctor.org has this quote from linus torvalds... Use AsciiDoc for document markup. Really. It's actually readable by humans, easier to parse and way more flexible than XML. — Linus Torvalds -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: people are doing interesting stuff (more)
http://jbt.github.io/markdown-editor/#HY+xcsQwCER7f8V2aZIr8kfIwhZzEngEOc/9fdB1sMPuPkgrGk/+crgNNmXczXKra1xSNNETLkM6zW9gM+1vSKCKX53eDlGXyiD8/lyUrkHzWe1WcJWw+di2vBbHNa1QSbPach+H7H89EAYZdEo6m93IPs+WIWcLFN4TIaN3652KTQp58Sd4UbG+ZJoO1lhk1Atn1ecJiZZRjJiUUjSKxdz5iKxf6s7+2P4B and here's someone who's done something similar, only it displays inside a 2-pane markdown editor. it is probably not difficult to imagine how this might become a collaborative editing environment, albeit one with the trait that it left no traces. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
kudos and major props
david said: I made something similar a few years ago yes, you did indeed. and i remember now thinking back then that it was brilliant. you even anticipated the url-too-long problem by using bitly, as well as combining several hashify into a single longer one. and this reminds me that other people have also been using the store-the-document-in-the-query-string approach recently. but as far as i know, you were one of the first. so kudos for that. do you know of any previous usage? if not, then major props... and now that you've had some years to ponder this technique, have you come up with any ideas for slick and inventive uses? not that it needs any, it stands on its own just for being clever, but if it has any additional functionality, i'd love to hear about it. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
markdown in a medium editor clone
markdown in a medium editor clone: http://ionicabizau.github.io/medium-editor-markdown/ -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
pandoc fully exposed online
finally... https://github.com/osener/markup.rocks -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Awesome Books (in Markdown)
gerald said: Again thanks for the great comments. sure thing. thanks for creating the resource. one thing i forgot. the most interesting thing about project gutenberg these days comes not from that project itself, but from an effort that calls itself project gitenberg, which is putting the p.g. e-texts into github, or rather a customized iteration of github that had to be created when the number of repositories (one/book) overwhelmed the regular system. of course, the entire github infrastructure is ridiculously complicated overkill for a task as simple as managing the very small edits that are typical of a finished p.g. e-text, but someone had a hammer they wanted to use. and sure enough, someone else had money to fund grants for people to use hammers, so -- you know -- the effort now has some legs. the reason it's interesting, however, is that one of the first goals gitenberg set out was to transform the e-texts into .html and then e-book formats, which is the very thing that was my intent when i focused on p.g. in 1999. (what i've learned, over the last 35 years, is that i'm exactly 16 years ahead of my time.) anyway... last i heard, gitenberg is leaning to asciidoc. that's a good plan, but they'll need to mod it. so, in the end, they'll have something that is exactly like z.m.l., light-markup for long-form. https://github.com/GITenberg/gitenberg.github.com https://groups.google.com/forum/#!forum/gitenberg-project https://news.ycombinator.com/item?id=8214564 -bowerbird p.s. gitenberg could also be using markua, which is scheduled to release an update on the alpha version of itself sometime _today._ markua is to be a markdown-inspired flavor that will be specially modified for long-form. so i guess you can say we have a trend now. for the record, asciidoc predated markdown, and it always had some focus on long-form. so did restructured-text, per its status as the light-markup used for python documentation. thus, once you start talking about _books_, markdown is lagging the field, considerably. but hey, it's never to late to muddy the waters! ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: never to late
i said: hey, it's never to late to muddy the waters! see? if this listserve were stored in github, i could correct that error to never too late. thank goodness for github... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Awesome Books (in Markdown)
gerald said: the idea is to have the source AND the rendered book in hypertext aha! great point. i see the utility now... For Project Gutenberg you get the source (but not a rendered book) which is where i entered this thread... :+) as, indeed, for some time, p.g. has offered .html versions of all its newly-done books, and even .epub and .mobi/kindle versions... once you understand the p.g. conventions, it's relatively easy to leverage them and generate .html at will. indeed, it was my effort to do that, at scale, for the whole library -- as it approached 10,000 books at the time -- which led me to first make z.m.l., during the period of 1998-2003... _however!_ the .html versions over at p.g. are usually _not_ auto-generated from their plain-text file... no, instead, the process by which the .html file is created is left to the individual in charge of the book, so that means each book is its own snowflake, similar to each other, but unique, in ways that are not apparent without close analysis. so inconsistencies in the e-text versions have been doubled in the .html versions! as you can imagine, this makes updating the library extremely difficult, virtually impossible. even the generation of the e-book formats has been fraught with problems due to that. back in 2003, i was unsuccessful in getting the p.g. powers-that-be to grok the power of z.m.l. to create and maintain a cyberlibrary. they constantly informed me a light-markup system won't work and mocked me for it. they wanted to use t.e.i. instead, while the minions who were doing the real work preferred to create their own snowflakes, and rolled their eyes at complex t.e.i. the conflict would've been comical, but their mistakes led to the decline and fall of the world's very first great cyberlibrary. 50,000 e-texts now, but a shadow of itself. and for Leanpub you get the rendered book but not the source. yeah, i've often thought that that's very ironic. you don't get the most useful version of the book. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Awesome Books (in Markdown)
gerald- gosh, i think that's the second time i've called you gerard, instead of _gerald._ my apologies, again! -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Awesome Books (in Markdown)
gerard said: Might be great to get some classics (in the public domain) e.g. Shakespeare, Dickens and friends. your other page, gerard, gave a nod to other forms of light-markup, including restructured-text, asciidoc, textile, etc. so i'm unclear if this page now means markdown in the john-gruber sense, or a more-generic light-markup way. because project gutenberg was using light-markup -- i.e., a structured form of plain-text -- since its start in 1976... the structure was often a bit wobbly, as you would expect, given progress -- the earliest e-texts had no lower-case, originating on key-punch machines -- and it was only lightly enforced upon volunteers who comprise the project, and it was terribly inconsistent as well; _but_ it was solid enough, advanced enough, and consistent enough, that i used it as the foundation for my z.m.l., a light-markup that _targets_ long-form. so, you know... if you want examples, project gutenberg has 40,000-50,000. -bowerbird p.s. leanpub.com has a bunch as well. and the guys over there are, right now, developing markua, their own flavor of markdown/light-markup for long-form... p.p.s. columbus didn't discover america. p.p.p.s. https://github.com/rhythmus/markdown-resources ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
js syntax highlighting for markdown (not for codeblocks in markdown)
honest question: why specifically is it that you would like syntax highlighting? i can imagine benefits, but am uncertain exactly which one(s) you're looking for. the reason i ask is that i believe that it might be possible to get what you want via easier means. but i'm just not sure what it is -- precisely -- that you want... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
fiddle.md
i keep thinking everyone has seen sites like this: http://fiddle.md but then yet another one pops up, and a new group of people say this is such a good idea! https://news.ycombinator.com/item?id=9262260 contrary to its claim, fiddle.md isn't collaborative, and isn't even particularly well-done, to be honest. but the parents seem to be fairly excited about it, so i think they are going to continue working on it. i'd still say that dillinger.io is the best of the bunch, although stackedit.io is also great. but i'd welcome any comparative reviews by actual hardcore users. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
wrapping it around
i thought when i made z.m.l. that we were at the very end. now, though, the new york times has wrapped it back around with the debut of archieml, or aml. i worry that this means we are destined to go through the entire alphabet again? -bowerbird p.s. i appreciate how the times has agreed with my shift from an emphasis on readability to one on writeability instead. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: serving markdown directly : any suggestions?
converting light-markup to .html ain't rocket-science. really. you can use any language to do it. specifically including perl. and besides, i think it's kinda cute that some perl people would look down on php, ruby, and python. good for the gander, eh? but if i had to place a bet, it would be on client-side javascript... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
mou makes its funding goal for a 1.0 release
mou, as you may know, is a markdown editor. with its second $5,000 company sponsorship, mou has reached it's $20,000 indigogo goal... albeit, the effort engendered some resistance: http://weblog.masukomi.org/2014/10/09/why-i-wont-be-backing-mous-crowdfunding-campaign the big thorn is that, because mou's developer has lost interest in the project, trying to sell it, a mou user stepped up to code an equivalent. that led the mou developer to resume his effort, issuing proclamations about the crappy clones in his campaign to raise $20,000 to release 1.0. (in all the time it's been out, mou's been beta; the goal to open-source the code is $100,000.) i take no side in this dog-fight. i have no argument with developers getting paid. and i am not religious on the open-source sauce. i even think open-source/proprietary tension can -- in some cases -- create benefits for both sides. i also believe in supporting developers who have built a tool that i use constantly, like my text-editor. i've paid the mere $15 asked by the tex-edit guy several times, because i appreciate it that much. i just paid it again, because i appreciate the app. http://www.tex-edit.com i'm curious, however, if anyone cares to voice any opinion about how such tension should shake out. because it's certainly possible to release code that lets people have a light-markup editing environment. i'm about to do that, on the way to doing other stuff, just because it is nearly an inevitable consequence. i'm sure you've all realized that there are a ton of free web-based markdown editors out there today. it's gonna be harder and harder, it seems to me, for any app developers to add value to what's coming, in a sufficient way so many users will end up paying. but maybe i'm wrong? -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re:
virgil said: Is there any way that the developers can come together on this very small part of the Markdown world? i'd have to say it looks like your answer is no, virgil. if it's any consolation, it's not you; it's always like this. have a nice weekend. have a nice november. have a nice 2014... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: Using fragment identifiers with Markdown docs
sean said: It is useful to say things like readme.md#how-to-install So that a Markdown editor could scroll to the right content. yes. indeed, that's a useful feature in many contexts, including ones where no such id exists in the .html. see: https://medium.com/@bbirdiman/lets-please-use-hashtag-terms-to-create-_arbitrary_-deep-links-f9185d5da2f0 a little bit of javascript can go a long way. *** Do any such editors exist? some of my tools have this type of sync functionality. and even if none _do_ exist, they certainly _could_. so i don't really see the usefulness of such a question. MultiMarkdown (and others) already offer automatic label generation (for HTML, LaTeX, others) that allow linking within the output document. unfortunately, however, there is some disagreement on the format that is used for such automatic labels, so neither users nor developers can depend on them. does this sound like a familiar type of problem? and is it any surprise the developers themselves seem not to know about these inconsistencies? I'm not aware of any editors that do this (directly) on the raw text side, but MultiMarkdown Composer (and others) offer the Table of Contents approach, and Composer allows you to accurately synchronize scrolling between the HTML and raw text, so internal links can be used to navigate the document already. more or less, kind of, yes. but not exactly that, not really. but there's no reason such functionality can't be offered. indeed, it's easy. john macfarlane asked, a while back, how to do it, and i gave him the 4-point pseudo-code... https://pairlist6.pair.net/pipermail/markdown-discuss/2014-August/003110.html -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: let us not discuss that here
i sent jakov a reply backchannel. take it all backchannel please. here's a post i made elsewhere, but i think it's relevant here too, in case anyone has any feedback. - call me crazy if you like, i don't mind, but... there's no need to plan for 20 to 40 years. by then, there will be no need for markup, markdown, or mark-all-around-the-town. it's not that difficult even now to figure out fairly unstructured text, so once we humans make slightly smarter programs and accept a responsibility to write in a structured way, with no room for ambiguous interpretation -- which really isn't as hard as you think -- we'll be able to leave explicit markup behind. it will be zen. i say this because i was able to ascertain the structure of project gutenberg e-texts without too much difficulty in most cases. likewise, you can scan a print-book and do o.c.r.. on the scans, and get output which also reveals the structure of the underlying text in a straightforward way. if you want to see that on a large scale, examine google books, which offers stuff which it ascertained, like header markup and a respective linked table of contents. that stuff certainly wasn't marked up in the print-book, but it just isn't that hard to figure out either, from the data available, if you ponder it a while, and apply yourself. in fact, i wouldn't be the least bit surprised if google can already grok unstructured text, because they have the firepower to solve it. heck, i'm merely a garage hacker, and i have achieved much of the solution all by myself. this light-markup stage is just a little path, meant to show us the way to a bright future. -bowerbird p.s. but since i'm here now anyway, i might as well tell you part 5 is up: beyond markdown -- part 5 -- shining a spotlight on sections and headers https://medium.com/@bbirdiman/beyond-markdown-part-5-4902097723b0 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: let us not discuss that here
i got a chuckle out of the fact that jeff atwood instructed me that i was not allowed to point to the beyond markdown series on medium.com, on the commonmark forum and then proceeded to _delete_my_comment_where_i_had_given_a_link._ i considered my comment to be an on-topic reply to an on-topic post (by someone who also posts here), but, heck, i'm not a moderator, so what do i know? -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: let us not discuss that here
oh, crap, i forgot to mention that beyond markdown -- part 4 is now available for your perusal. ;+) https://medium.com/@bbirdiman/beyond-markdown-part-4-9b4dc6841d7e if you'd like to discuss anything, send me an e-mail. thank you. -bowerbird p.s. and if you know jeff atwood, feel free to share the link with him. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
money for mou
interesting to see if there is any demand: https://www.indiegogo.com/projects/mou-1-0-markdown-editor-on-os-x-for-you -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
let us not discuss that here
ubi said: shouldn't this be moved to some other mailing list? i sent only one notification, of the series, and that was because i did not want to be seen as dissing markdown without giving a fair notice. and, for the record, i'm _not_ dissing markdown. i'm doing what john gruber has always suggested, which is to make my own thing, with its own name. and, just for the record once again, i didn't need his instruction or permission to do that, because i was working on z.m.l. for many years before markdown. and i've continued to work on my system long after he pushed markdown out of his nest to make it fly. *** I guess Markdown purists (is there such a thing?) may be annoyed. if markdown purists want to be annoyed at something, i'd suggest they read my medium article from last year: markdown considered harmful https://medium.com/@bbirdiman/markdown-considered-harmful-495ccfe24a52 that article is eminently fair, but the internet knows that has never stopped some people from being annoyed. *** i don't want to discuss any of the specifics of my system on this listserve, for various reasons, but i think i must correct a few misimpressions from the feedback here. I don't know how I feel about having to add a (which by your convention is a placeholder for [space][space]) for every line. you don't have to put aon every line; putting it on the first line will be sufficient... thanks for showing me i should've said that. what if the block-quote text is not poetry? z.m.l. offers two different block-quote tags: one retains the linebreaks, the other doesn't. even in the form where lines are rewrapped, there is a way to specify a specific linebreak should be retained. (it is the method that is used across the whole of z.m.l., so i didn't want to discuss it there in that one context; i will discuss it as a general rule, later on. but thanks for showing me it is confusing.) *** mofo said: I do wonder if people would be willing to use the [space][tag][space] system though. E.g. when typing '', will I be willing to tolerate having to add an extra space? Will be interesting to see how tolerable it is. um, ok. if that is my biggest problem, i'll have huge problems and no problems, simultaneously. Also what is a chunk anyway? beyond markdown -- part 2 -- z.m.l. is built to be easy to understand https://medium.com/@bbirdiman/beyond-markdown-part-2-b3527d2b9dcf any set of non-blank lines bordered by blank lines is a chunk. (though there will be a future wrinkle, in that there'll be occurrence of empty chunks, a result of splitting the file on double-linebreaks.) Does that include header? most definitely. headers will be fully discussed in part 4 or part 5. I might find having to do that space thing to be annoying for headers you always have the comfort of markdown as a fallback. *** ok, now let us not discuss this any more here... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
september is still the cruelest month
maybe perhaps it's time to go beyond markdown. i don't want to talk about you behind your back... and do please let me know if i get anything wrong! https://medium.com/@bbirdiman/beyond-markdown-part-1-2300665659f7 https://medium.com/@bbirdiman/beyond-markdown-part-2-b3527d2b9dcf subsequent parts should come relatively quickly... hey, the background graphic for part 2 is a photo i took last night out at chavez ravine, shortly after kershaw tripled in a run to tie the game in the 5th; clayton went on to get his 21st win of the season, as the dodgers clinched the national league west. in other news, the yankees were eliminated from the playoffs. nontheless, re2pect to the captain... -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
clarification of terms would be a good thing
fletcher said: this is NOT Markdown when you do this. thanks for your guidance on this, fletcher. today's world seems to be confused about what markdown _is_ and what it is _not._ perhaps a good explanation would be useful? you know, one that defined markdown explicitly, so we knew what it _is_ and what it is _not_... lacking that, perhaps some good examples might help. for instance, _this_ is markdown, but _that_ is not, nor are _those_other_things_. maybe draw a line down the middle of a sheet of paper, and on one side write the things that _are_ markdown, and the other side _are_not_. start with commonmark. markdown? or not? -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
big companies and bloated code
so i'm finishing up my latest example of a working light-markup system, and it's running under 45k at the moment. i thought i'd include embedding in it; you know, the typical stuff from youtube, and twitter, vimeo, vine, instagram, etc. my word. embedding from these big companies involves some extremely bloated code, ranging anywhere from 150k up to 950k for every single one of 'em. i kid you not. excuse me? after i've worked so hard to cut my code to the bone to make it as small as i can? i even did the grunt work of converting to vanilla javascript, so i could drop jquery. and guess what? an instagram embed downloads jquery! it's version 1.7.2, so it only weighs 95k, but by itself it's twice the size of my code. (an instagram embed is 750k, which does _not_ include the featured media itself.) worst is the fact that some of this bloat is for tracking users, and my preference is to not even include such invasive code for my own useful purposes, let alone the probably-evil aims of these corporations. and, on top of all that, their complex code sometimes screws up the understanding and execution of my _simple_ code. argh! so if i do end up offering such embedding, it'll be with a big dose of warning to users. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
re: wysiwyg and light-markup are oil and water
mofo said: I think a mark down wysiwyg would still be very useful, even if not perfect except it wouldn't be anywhere near perfect. i'm saying that it is, in the end, _unworkable._ Take for instance Adobe dreamweaver. It can edit both in output mode and in source code. except that's explicitly _not_ wysiwyg. not at all. rather, it's a multi-mode environment, where you _switch_ between fully different representations. (again noting wysiwyg means _so_ many things.) The ability to switch between two views is a lifesaver. right. because sometimes what you do in one view screws up stuff in the other, and it cannot be fixed without switching to work in that other environment. thus, what you end up with when you try to mush the two environments together is the worst of both worlds, where you can't tell for sure whether it's right or wrong, and -- if it's wrong -- you don't know how you can fix it. this example upholds my point, it's not a counter to it. Plus this is a good opportunity to push the idea of separation between presentations and text for typical non tech savvy office workers. yet another case of not choosing your battles carefully. for all of these issues, a much better solution is the two-up interface with both your input and the output, in the form almost all the good implementations use (i.e., edit on one half the screen, display on the other): dillinger, ghost, mmd-composer, stackedit, markable, and a host of other tools, not to mention marked2.app. if you can show me any wysiwyg implementation that works anywhere near as well as any of those tools, do. or any tool that tries to mush together input and output. even medium, with all of evan william's money, cannot work it well for more than a meager handful of features. i'm not going to review the attempts, because it would be overly cruel and i sincerely wish 'em good luck, but as far as i can see, it will take some big breakthroughs. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: wysiwyg and light-markup are oil and water
mofo said: Yea, but I want to see more of the actual output rather than the markdown representation. But I don't want to lose track of what parts of the output can be seen in the now 'smaller' input i'm not following you. but i'm sure it's just a simple matter of terminology. when the _input_ field is showing any specific paragraph, users should be able to summon that spot in the output, i.e., automatically scroll (or sync) to that paragraph. or, in cases where they prefer to do it the other way, when the _output_ field is showing a specific paragraph, users should be able to summon that spot in the input, i.e., automatically scroll (or sync) to that paragraph. i think both of those are very straightforward. now, as i've said before, doing sync between the fields at any other time (or, indeed, on a continuous basis) is not as simple a matter as you might suppose at first. (per the example i just gave, which way do you sync?) I do hope somebody does give 'editable' output view, a shot. me too. and people are, to be sure. Maybe it might not be too stupid an idea in practice. i never said the wysiwyg markdown idea was stupid. what i said is that my research/thinking indicates it is _unworkable_, which is a very different thing entirely. so if someone proves me wrong and makes it workable, it _might_ be a great idea. (or, we must say, it might not, because it still mashes content in with presentation, but i'm not one of those people for whom this is sacrilegious.) but, until someone makes the idea work, it's all irrelevant. *** michael said: I just added a toggle for source view, so one can check and edit the source. that's a good addition. i was perplexed when i pasted in markdown text and it wasn't recognized and formatted correctly. that was a serious violation of my expectations... and i still don't know if that should work, or not. Actually I don't think it is the goal that people learn or type Markdown. we -- you, me, everyone -- choose our own goals. live and let live. Why should a person who only wants to write down some content switch to Markdown. They are used to WYSIWYG editing, and with Markdown hidden in the back end they get the Markdown publishing environment for free. make it work. i wish you luck. i'm rooting for you. imagining the output from the input is hard for many people, have both next to each other seems the current way to go, but be honest that is a crutch and not end user ready. i'm not sure i agree with your bottom line there, but it's not worth disputing. :+) What if the output determines the input? then we will need to switch the terminology we use. plus your level of complexity will increase significantly. One has to formalize and parse the user input and that is hard. that's not why i say that combining the views is hard. it's because if you show all of the input characters, then you will have compromised the wysiwyg value. but if you do _not_ show all of the input characters, then you will have compromised the ease of editing. some apps try to escape this dilemma by showing the invisible input characters in a gray font, but -- in my opinion -- that is the worst of both worlds. One has to have in mind, that not all formatting and content can be resembled in Markdown and Marko Editor only takes from a paste what it can handle, so again what you see after a paste in the editor is what you get right there you will have violated one of the main expectations that people have for a wysiwyg tool. (and, again, wysiwyg means _so_ many things!) but as the saying goes, i don't want to interrupt your success by telling you that it can't be done. so go do it! prove me wrong! :+) -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
the basic gruber markdown basics
# THE GIST OF MARKDOWN'S FORMATTING SYNTAX ### an adaption from text by John Gruber http://daringfireball.net/projects/markdown/basics ## PARAGRAPHS A paragraph is simply one or more consecutive lines of text, separated by one or more blank lines. Normal paragraphs should not be indented with spaces or tabs. Now is the time for all good men to come to the aid of their country. This is just a regular paragraph. The quick brown fox jumped over the lazy dog's back. ## HEADERS Markdown offers two styles of headers: setext and atx. Setext-style headers for `h1` and `h2` are created by underlining with equal signs (=) and hyphens (-), respectively. A First Level Header === A Second Level Header - To create an atx-style header, you put 1-6 hash marks (#) at the beginning of the line -- the number of hashes equals the resulting HTML header level. # Header 1 ## Header 2 ### Header 3 Header 4 # Header 5 ## Header 6 so much for headers. ## BLOCKQUOTES Blockquotes are indicated using email-style angle brackets. This is a blockquote. ## EMPHASIS Markdown uses asterisks and underscores to indicate spans of emphasis. Some of these words *are emphasized.* Some of these words _are emphasized also._ Use two asterisks for **strong emphasis.** Or, if you prefer, __use two underscores instead.__ ## LISTS Unordered (bulleted) lists use asterisks, pluses, and hyphens (*, +, and -) as list markers. These three markers are interchangable. * Candy1 * Gum1 * Booze1 + Candy2 + Gum2 + Booze2 - Candy3 - Gum3 - Booze3 * Candy4 + Gum4 - Booze4 hr * Candy5 * Gum5 * Booze5 hr + Candy6 + Gum6 + Booze6 hr - Candy7 - Gum7 - Booze7 hr * Candy8 + Gum8 - Booze8 Ordered (numbered) lists use numbers followed by periods as list markers: 1. Red1 2. Green1 3. Blue1 1. Red2 1. Green2 1. Blue2 9. Red3 9. Green3 9. Blue3 hr 1. Red4 2. Green4 3. Blue4 1. Red5 1. Green5 1. Blue5 9. Red6 9. Green6 9. Blue6 hr 1. Red7 2. Green7 3. Blue7 hr 1. Red8 1. Green8 1. Blue8 hr 9. Red9 9. Green9 9. Blue9 If you put blank lines between items, you'll get `p` tags for the list item text. You can create multi-paragraph list items by indenting the paragraphs by 4 spaces or 1 tab: * A list item. With multiple paragraphs. * Another item in the list. ## LINKS Markdown supports two styles for creating links: inline and reference. With both, use square brackets to delimit the text to turn into a link. Inline-style links use parentheses immediately after the link text: This is an [example link](http://example.com/). Optionally, you may include a title attribute in the parentheses: This is an [example link](http://example.com/ With a Title). Reference-style links allow you to refer to your links by names, which you define elsewhere in your document: I get more traffic from [Google][1] than from [Yahoo][2] or [MSN][3]. [1]: http://google.com/ Google [2]: http://search.yahoo.com/ Yahoo Search [3]: http://search.msn.com/ MSN Search The title attribute is optional. Link names may contain letters, numbers, and spaces, but are not case sensitive: I start my morning with a cup of coffee and [The New York Times][NY Times]. [ny times]: http://www.nytimes.com/ ## IMAGES Image syntax is very much like link syntax. Inline:  Reference-style: ![alt text][id] [id]: http://zenmagiclove.com/simple/gruber-logo2.png optional title ## CODE In a regular paragraph, you can create code span by wrapping text in `backtick` quotes. Any ampersands () and angle brackets ( or ) will automatically be translated into HTML entities. This makes it easy to use Markdown to write about HTML example code: I wish SmartyPants used named entities like `mdash;` instead of decimal-encoded entites like `#8212;`. pI wish SmartyPants used named entities like codeamp;mdash;/code instead of decimal-encoded entites like codeamp;#8212;/code./p To specify an entire block of pre-formatted code, indent every line of the block by 4 spaces or 1 tab. Just like with code spans, , , and characters will be escaped automatically. To specify an entire block of pre-formatted code, indent every line of the block by 4 spaces or 1 tab. Just like with code spans, , , and characters will be escaped automatically. # for use in doing first-line basic testing of markdown systems ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
wysiwyg and light-markup are oil and water
there is a lot of surface appeal to a system which combines wysiwyg and light-markup. and one can do a few simple combinations. but before long, and certainly once you try to tackle some more-complicated features, you find yourself torn by an inherent conflict. starkly put, there is a _difference_ between what you put in, and what you get out, and the question is which one you want to see. by definition, wysiwyg pictures the output. but an inability to see your input means it can become very difficult to edit that input. the inclination, upon that realization, is to attempt to show enough of the input that it becomes possible to do your editing, but that just turns the wysiwyg into cruel illusion. i'm not gonna say that it's impossible, but i will advise anyone who is tempted to try it to carefully map everything you need to do before you even start to think about coding. if you want to take on the hardest thing first, figure out how to successfully allow a paste from an arbitrary ms-word file... good luck... -bowerbird p.s. even if you solve that fundamental gap, you will also discover that wysiwyg carries excess baggage, in that some people think it entails one thing, and other people another, so you're never gonna make everyone happy. p.p.s. all this also applies to contenteditable, in case anybody is mulling that as a solution. ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
the trains are already leaving the station
i said: and get on board this new, better model, with a good algorithm. maybe the way you did it before was good enough for back then, but the future _will_ leave you behind if you do not get on board. _however_, you might want to wait, for maybe a month or two. because macfarlane's _model_ isn't yet as clear as it should be... well, maybe just maybe you shouldn't wait after all. i'm sure the model will change, perhaps quite a bit, but programmers are already stepping up to bat and there are only so many converters that need coding. in addition to official converters from john macfarlane -- one of which is written in c, the other in javascript -- commonmark already has two more in other languages. in php: https://github.com/colinodell/commonmark-php in c#: https://github.com/Knagis/CommonMark.NET hopefully the commonmark team will vet these converters, to ensure they're currently accurate and will be maintained -- not just to give correct results, but also _work_ correctly -- and prevent a flock of me-too forks muddying the waters... a solid line of converters, sleek but complete, is all we need. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
on the curve
john macfarlane said: When you try to fit a curve to a bunch of data points (which is what writing more precise rules for Markdown involves), the best fitting curve will probably not pass through all of the points. you have shown a great ability to fit a curve to some disjointed points, befitting the mental gymnastic flexibilities of a professor of philosophy. now wipe that clean and do it again, with the object of plotting a curve which is _simple_, and beautiful, and lean, and elegant, and graceful. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
fast sailing on the way to a clearer model
john macfarlane said: CommonMark, which provides two implementations that use the same parsing algorithm, one in portable C and one in 1540 lines of javascript bingo. The javascript implementation doesn't use any unusual javascript features and should be straightforward to port to other dynamic languages: perl, python, ruby, PHP. double bingo. (Or you could just use the javascript library client-side and skip the server-side rendering.) triple-bingo. The parsers are both fast and accurate. accurate is assumed. so, for fast, let's have the numbers. (i'm ostensibly writing this reply to john, but really to michel, and to everyone else on this list, because i know macfarlane already recognizes this, and i know some of you others don't.) without changing the algorithm, has managed to make it about as fast as sundown, which is very fast indeed (0.01 seconds to parse a 1MB document, for example). When optimization is complete, it should be even faster. first of all, let me just say that, from a user's perspective, any conversion that happens in one second is fast enough. so if you're talking 100 times faster than that, you're good. now let's put this into perspective. a 1-megabyte document is a book, and not a small one. a small book -- alice in wonderland -- runs at about 150k. a medium-sized book is anywhere between 400k and 600k. and a _big_ book weighs in at around the 1-megabyte range. (moby dick is 1.2-megs. war and peace is 3.2-megs huge; but then again, it was also split up into 15 different books.) so let's say that, as a general rule-of-thumb, you can assume that 99.9% of your needs are gonna fall under the 1-meg mark. so if you can keep it under a second, or even two, you're good. The javascript parser is also very fast (0.28 seconds for the above-mentioned 1MB document, running in the Chrome browser). so, you're good. Markdown.pl takes 250 seconds on the same input really really really bad. but you knew that before you started. and pandoc takes 3.19 seconds. not good. not really bad, on a 1-meg file. but room to improve. ok, actually, considering that pandoc runs in a batch modality, 3.19 seconds is fantastic. but nobody really wants to do batch when they could instead be doing on-the-fly immediate reactive. so you're gonna have to have an editor, and a web-app, wherein a 3.2-second turnover will seem pokey to today's spoiled users. so you're gonna need a definite improvement. *** and you _have_ definite improvement, thanks to a better model, to the point that performance metrics are no longer your concern. you're way past fast enough, even on huge files, so you can now shift your focus to all of the other things you should be prioritizing. and now i'll say it a third time, so everyone besides macfarlane understands exactly what i'm saying: throw away your flavors, and get on board this new, better model, with a good algorithm. maybe the way you did it before was good enough for back then, but the future _will_ leave you behind if you do not get on board. _however_, you might want to wait, for maybe a month or two. because macfarlane's _model_ isn't yet as clear as it should be... and now i will speak to macfarlane. (but y'all should listen too.) this is the point where i basically throw all this back in your lap. because i now respect you as a worthy competitor to my system. and i don't need to be giving free advice to a worthy competitor. (and not to put too much stress on the competitor aspect, since i think it's a win-win situation, and nobody's extracting any cash. besides, you might not even see me out here on the playing field, let alone think that i could be capable of giving _you_ any advice.) but i also imagine you are getting lots of advice from elsewhere. and i don't feel any big need to be a part of that bellowing chorus. but there's a definite weakness in your approach, and i suspect that you know it yourself, so here goes: it is too complex for the users. yes, you've improved gruber's system by eliminating ambiguities, but you did it by creating additional rules on how to handle them, via what, 159 examples?, which is a very heavy burden for users. you need to lighten the load for them, or you don't stand a chance. specifically, stop retaining the backward compatibility with gruber. instead, ditch the aspects that are _causing_ all those edge cases, so you can boil things down into a cleaner mental model which is conducive to giving your users a more transparent understanding. i know, i know, you've spent years and years trying to fit yourself into his mental model, so it's very difficult now to let yourself out of that fenced area to run free, suffering as much as you have from stockholm syndrome, but gruber had a very inferior understanding. if you toss out _everything_ from him, and start over from scratch, first you will experience a remarkable feeling of freedom, and then
on syndromes and naming and promotion
michel said: I have some doubt it'll be fast enough in PHP. i don't enjoy telling you that you are wrong. certainly not when i know that it engenders your resistance. but i say it anyway, because you need to know when you are wrong. and i don't enjoy saying i told you so. certainly not when the things i am saying are so darn obvious. but i say it anyway, because you need to know when i was right. so let me call this one out loudly and clearly: you are wrong. if you use john's algorithm, it _will_ be fast enough. and when you discover that it is, i will say i told you so. it might well end up being faster than your current version. i'm not predicting that, but i would be surprised if it wasn't. but what is most important is that it will be fast enough. regardless of performance, I can't swap my algorithm with your algorithm and still call it PHP Markdown if it gives significantly different results. CommonMark does not pass the PHP Markdown test suite, neither does it pass the original test suite made by John Gruber. so not only do macfarlane and commonmark have to conquer their own case of stockholm syndrome, but also that of others. oh well, challenges make success that much sweeter. but lord knows the world will be stronger when people discard that rickety framework that markdown has been saddled with... My understanding is that CommonMark is a different flavor of Markdown that chose to diverge in a couple of small ways from the original. i don't know if that is an accurate characterization. _but_ i would highly recommend that commonmark _should_ take that approach, even to the point of intentional divergence. commonmark should refuse to offer any compatibility mode with gruber-markdown. force the choice to be crystal-clear. after all, isn't that precisely how gruber wanted things to be? he forced the issue. so now users deserve a clear choice. I could obviously fork it and fix things so they can pass my test suite and John Gruber's test suite and behave more like the original Markdown behave no no no no no no no. don't you understand, even at this late point in the game, that this forking behavior is what _causes_ the problem? if you wanna support gruber-markdown, use your old code. if you choose to be the php point person for commonmark, your job is to execute the algorithm faithfully, not fork it. if you're unwilling to do that, let someone else take the job. same for all you other developers with different languages. we need greater _clarity_, not forks that muddy the water. if I do port CommonMark to PHP I'd probably call it PHP CommonMark oh, absolutely. you _must_ change the name, because users deserve to know that they are making a _choice_. and promote it as an alternative, better defined, Markdown-like syntax. you don't have to do any promotion. none at all. if there was anything good that came out of this _mess_ when the announcement was botched so incredibly badly, it was the realization that a huge number of people were more than willing to blame gruber for being the asshole. um, sorry, folks. but gruber was being perfectly reasonable insisting that the new effort not use _his_ markdown name. _perfectly_reasonable_. gruber has a way of being an asshole, sometimes, yes -- such as calling atwood a dicknose -- but markdown as a _name_ is something that _is_ his, so his insistence was utterly understandable and perfectly reasonable. a lot of people credit gruber for inventing markdown. pure bullshit. he stole the idea redhanded from textile, _and_gave_it_another_name_. but that name is _his_. and even on his recent podcast, he was good-humored when insisting the new effort use a different name too. indeed, that was the one-and-only-thing he asked for. and then atwood-and-company went and used the name. which, yeah, is really a dicknose thing to do. and then atwood-and-company went with another name that had the same problem as the first name. dicknose. so atwood-and-company had to surrender completely. (why cause that ugly war if you were gonna surrender?) but in spite of the fact that he was the reasonable one, lots of people still ended up calling gruber an asshole. why? because they're mad at him for the way he has ignored the problems with markdown and its flavors. they suffer from those problems, and want a solution. to the point that they are willing to denigrate gruber and take the side of dicknose atwood-and-company. unfair, sure, but it reveals the depth of resentment. lots and lots of people. and they _want_ a solution. i knew that resentment would manifest _eventually_ -- as y'all know, since i've predicted it right here -- but not even i realized that it's already very strong. so people were willing to excuse the belligerence of atwood-et-al to get some markdown solutions. give people those solutions and you won't need to do promotion. they will knock your doors down.
when rational discussion was still a possibility
michel said: If you want to start a discussion about that new Markdown-related thing making rounds on the internet i don't want to start such a discussion. but i find it very perplexing that so many of the people here -- who i assume are here because they _care_ about markdown -- would allow themselves to be diverted by a topic as trivial as _tables_ when the internet at large is more-or-less talking about the evolution of the future of this format/tool/whatever. how about asking for opinions about it? anybody who wanted to express an opinion about the new thing could have done it here last month, when john posted it to this listserve, and rational discussion was still a possibility. which is certainly not true in the zoo which has since ensued. instead of writing poetic elephant analogies i am a poet, so if you meant that as a dig, well, it didn't work. and subtle meta-complains what exactly was subtle about my complaint? nothing at all. i mean, it's certainly possible that the initial poster was unaware of the large kerfluffel surrounding markdown out on the internet, because a healthy disregard for the social media is... healthy... but certainly _some_ of you had to have some knowledge of it. and yet everybody is just going about your business as usual. No one bothered announcing the news here yes, that was one of my points. so no one is discussing it here. yes, that was another one of my points. If you think it's worth a discussion, start one. i think there are a whole raft of questions that are being obscured by this battle of personalities which are worthy of discussion and -- indeed -- _should_ be discussed in a healthy dialog involving all sides. but i also have _more_ than enough experience to know that such a discussion will never happen here. i am also aware that even if it _could_ happen here, it'll never be the case that _i_ would be permitted to start it. that's not something an outsider is allowed. (but hey, if you want to play, chew on this for a bit: could we eliminate ambiguities and inconsistencies, while still retaining the flexibility that gruber desires? and if so, how exactly would we go about doing that? here's a good hint: do not let atwood lead the effort.) But please don't start it by complaining how unacceptable it is that it isn't already being discussed, it's quite uninviting. i didn't say it was unacceptable. i accepted, a long time ago, that _nothing_ of substance will ever happen on this listserve. and i'm fine with that. but when _nothing_ happens in such a noticeable way, i'm gonna notice it, and i'm also gonna comment on it. because that's what an outsider does. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
that's pretty close to what i've done
# that's pretty close to what i've done gerald said: I'd say using a webcomponent (custom HTML element) with an HTML import should get you (almost) there. yes, that's pretty close to what i have done: http://zenmagiclove.com/misc/s/side-by-side-v4.html -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
what i meant by simple
# what i meant by simple ## table of contents what i meant by simple table of contents about the message i posted what gerald said what john said what i mean by simple my general responses my code was also less than perfect and now no framework required what this code facilitates on the matter of doing sync determining the line the cursor is on ## about the message i posted first let's look at what people said about my post. ### what gerald said gerald said: I published a simple single static HTML page side-by-side markdown editor about a year ago. http://geraldb.github.io/markdown-note/note.html ### what john said john said: the dingus I linked to before has side-by-side editing http://jgm.github.io/stmd/js ## what i mean by simple i realize that i neglected to mention my operationalization for the word simple in the context of that sample code i posted. my goal was to demonstrate that an .html file -- by itself -- is sufficient. the absence of any framework is thus crucial. most people prefer to use the framework of _their_ choice. *** ### my general responses gerald, your code will be simple in a ruby-on-rails setting. but anyone who doesn't know ruby-on-rails is gonna be lost. and john, your dingus has a lot of bootstrap dependencies. *** ### my code was also less than perfect of course, as i noted, the code i posted required jquery, so it wasn't completely pure in terms of my now-stated goal. so, as an exercise, i reworked the example just a little bit: http://zenmagiclove.com/misc/s/side-by-side-v2.html ### and now no framework required you can verify this new code requires no framework at all. i eliminated the jquery by converting to vanilla javascript. in a real editor, there are enough wrinkles that jquery is more-or-less a requirement anyway, but this is an exercise. i also hand-coded a very crude conversion routine, so that there is no need to call a converter from the internet either. the conversion routine is embedded right there in the page. ### what this code facilitates this allows a person to download the light-markup text itself, and have it converted to .html _client-side_ for display there. it also allows the .html file to be used in an offline context, provided that you grok the resultant complications of saving. but the cool thing is client-side conversion of the light-markup. in this sense, similar rad stuff has been done by strapdown: http://strapdownjs.com for the strapdown version of this message, see here: http://zenmagiclove.com/misc/s/strapdown-v2.html *** ## on the matter of doing sync john said: It should be possible to add some degree of syncing, since the stmd parser includes source position information in the syntax tree, and this could (with some changes to the HTML writer) be included in the HTML output one could enable syncing in that way, most definitely. i do it another way, but whatever works is worthwhile. ### determining the line the cursor is on john said: I never did figure out how to determine using js which line of the input source the cursor is on, but presumably this is possible. 1. get location of the editfield cursor. 1. get copy of text up to the location. 1. put the copy in a dummy textarea. 1. use dummy height to compute line. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
