dean allen is gone

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

bear design award

[bowerbird via Markdown-Discuss]

apple gave a design award to "bear",
a light-markup word-processing app.


http://www.bear-writer.com




https://developer.apple.com/design/awards/#bear


-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 ;-)

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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: Manuscripts - New Book Format for Markdown

[bowerbird via Markdown-Discuss]

should be ready "real soon now"...


>   http://markua.com


>   https://leanpub.com/markua/read


>   https://github.com/markuadoc



yet another markdown flavor,
specialized for book creation,
from the humans at leanpub...


-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.

[bowerbird via Markdown-Discuss]

shane said:
>   Wow - that's impressive!


yes, it is.


i was fairly skeptical of the commonmark effort -- 
xkcd.com 927, lowest-common-denominator, etc.
-- but i have to give 'em credit for this script here.


i once said that i thought multmarkdown had the
edge to be leader of any markdown convergence,
because the offline app was a huge advantage...


but now, with electron, any javascript routine can
be bundled into offline apps, which means that a
fundamental shift in the tipping-point has occurred.


and with node-js, commonmark could set up a site
with an api and do all server-required conversions.
the bandwidth charges might become fairly hefty,
but setting up the site is probably a eight-hour job.


with server and client handled, bingo consistency.


hasn't happened yet, and might not, but the path
is now fairly clear, for people who want to see it...


in my humble opinion.


-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.

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

> 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

[bowerbird via Markdown-Discuss]

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

markua -- a new flavor for long-form documents

[bowerbird via Markdown-Discuss]

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?

[bowerbird via Markdown-Discuss]

aristotle, your mockery entertains me immensely.

-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?

[bowerbird via Markdown-Discuss]

david said:
>   Compare the manually specified
>   https://github.com/plaid/sanctuary#either
>   to the auto-generated
>   https://github.com/plaid/sanctuary#either--a---c---b---c---either-a-b---c

ok, first of all, if you manually specified this anchor:
>   https://github.com/plaid/sanctuary#either
no way ever would i expect it to go to that location.

especially since this link:
>   https://github.com/plaid/sanctuary#Either
goes to another location. (told you about case glitches.)

nope, i would expect your manually-specified link to
go to the location where this link actually goes:
>   https://github.com/plaid/sanctuary#either-type

(ironically, that header actually has a capital letter,
but the anchor is nonetheless in all-lowercase. ha.)

no, the thing about "manually specified" anchors
is that they will show all kinds of idiosyncrasies.
so not only are they work to create, but they are
also inconsistent, thus undependable, meaning
you have to look at each one to see what it is, so
they have almost _no_ redeeming qualities at all.

furthermore, the github methodology must be
doing some kind of javascript-based search
-- which is not a bad idea, as i suggested here:

>   
> https://medium.com/the-bower/lets-please-use-hashtag-terms-to-create-_arbitrary_-deep-links-f9185d5da2f0

(grok that deep-link! hyphens _and_ underbars!
and random crap at the end just to confuse you.)

except whatever github is doing is implemented
very strangely, so is certainly not what i would do.

however...

***

alan said:
>   If I were to pick a preferred format for auto-generated IDs,
>   it would have to be hyphens. Separating words is desirable
>   as it is more readable. And underscores, though not a terrible option,
>   can be obscured by underlines when the entire URL is presented to a user.

i disagree with several of those points.

but, hey, our own personal opinions don't mean jack.

i would gladly accept _any_ method, even if distasteful,
as long as everyone agreed that that's what we're doing.

so what would make a difference is if all the flavors
would converge on a mutual-agreed-upon method.

but...

>   Of course, I've been on this list too long to expect
>   implementations to actually converge on much of anything.

right, that's never gonna happen, i think we all know that.

so, then, what we need is to poll a million users or so, and
see which of the possible solutions they would most prefer,
and then let that vote guide us. but that won't happen either.

so the guiding principle is this:

if it _is_ broke, but you know you can't fix it,
don't waste time and energy by even trying.
don't even discuss it. pretend it doesn't exist.
(that's something all the flavor-makers can do!)

i would suggest we have reached this point.
thank you for your question, original-poster...

-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?

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

kudos and major props

[bowerbird via Markdown-Discuss]

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

re: people are doing interesting stuff (more)

[bowerbird via Markdown-Discuss]

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

people are doing interesting stuff

[bowerbird via Markdown-Discuss]

http://channelurl.com/show/1f8b080084a9535500037d53c1929b300cbd6726ffa09e369b21ec7d3bfd924e0f06447031166bc9c9f2f7956cd24d2fe502587ad27b4ff28ab40604971006f2f10a3e0a2664b16f963c8ec7c38fff3ec7c3f120936710fc1438f9088b4bf340f70823a5c5c92b689085120e5a1d6442c86d6a43db808b0380c131424ff1864934c94e07cf6b709bfedd2d2893931d65d56e9ebd66b6b5b7863c37c0b4a056191048ab4d2e460c3985b6a7e5dd122f206e467e2200970bf08abd1f7def42d89a12fbc898b60b4b320b34c3e8547c8eabeb67062f200457945a2b0e98c266d97f959b17cd8eda853d60ed244ba8d28bee9ab4ebe5aab4e414754cf065aebe23c9c34ba5761e08eb197e7a96b39d616054cf12b666ad2fa8f39962d8cee787ffcf1235cd8fb0512e9e5d7128149a72a205ee94c3b0870a764166a7df5e18c308a73551e7bab0154b5cea34f65aa8fbb1a9c3b34a6562051f7c9cc17574c3da63a0f8a29a5097308422b6a9c45f18166251c08c5abec3de65c6bd066bf774d3bfe4782a9c6be5d29946353d27c6a69a879fae1770ab5275fda40a5cdc8d2eb27553d441edc9a84371a0d3da2090cdb36a6da1cbeaa331d28ba12c3fb2aedff355296d4f3ad3069e9abbb8953b6067c15f27b9d882e415aaa9774af3f7a2553708877d83174b54b
 
5b064e5daa16813606b3858b1a2f43775edabb5fc294ad5171dc9c6f1ed179c2691f5fdededdf1bf0a60bd6abe7a9c068d6d160086ddb1a3a10e9569bcf5f1352e374e20f3a6690d155c0f1f007470c58e83404



people are doing interesting stuff
==

this text (in markdown format) is stored in the u.r.l., and  
then converted and displayed when that u.r.l. is visited.

that is, some code on channelurl.com:

- takes the u.r.l. -- specifically, the query-string -- and 

- unpacks it to get the underlying markdown text, 

- converts it to .html, and then 

- displays that .html.

so this text is not stored -- *does not exist* -- elsewhere.  
it is **only** in the query-string.  if you changed that, you  
would change the message itself (probably to garbage).

if, when you visit the link above, you don't see all this,  
it's most likely because the listserve trashed the link.

of course, this exact approach means that you cannot  
send a very long message. but it's still quite interesting.

(and, of course, any form of light-markup would work;  
indeed, some might be much better suited for the job.)

[try it yourself!] (http://channelurl.com/discover)

ok, well... it looks like the link thingee might not work...

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

markdown in a medium editor clone

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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: never to late

[bowerbird via Markdown-Discuss]

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)

[bowerbird via Markdown-Discuss]

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: Awesome Books (in Markdown)

[bowerbird via Markdown-Discuss]

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)

[bowerbird via Markdown-Discuss]

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)

[bowerbird via Markdown-Discuss]

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

caddyserver.com

[bowerbird via Markdown-Discuss]

another prediction confirmed:

a new webserver which serves markdown directly,
without making users do a conversion themselves.

>   https://caddyserver.com

next we'll need to hook in some good templates,
to produce beautiful sites with powerful features,
so we can open up the world wide web once again,
like it was before the tech burden drove people to
the nice simplicity of silos like facebook and twitter.

-bowerbird

___
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)

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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?

[bowerbird via Markdown-Discuss]

it makes it too easy to remove inconsistencies

between all the different "flavors" if your users
know exactly which converters are being used,
so compile yours so it is as obscure as possible.


-bowerbird


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

re: serving markdown directly : any suggestions?

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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:

[bowerbird via Markdown-Discuss]

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

the issue with markdown was that it was too simple

[bowerbird via Markdown-Discuss]

  

https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272
  scott chacon, github cofounder, author of "pro git", on release of 

the second edition


  The issue with Markdown was that it was too simple.
  It didn’t specify things like table formatting, cross references,
  indexing, callouts, source code examples, etc.
  All of which Asciidoc does in a format that is just as easy to 

write.

if you want to correct someone, correct scott chacon. he said it, not 
me.


-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

[bowerbird via Markdown-Discuss]

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

just announced

[bowerbird via Markdown-Discuss]

this was just announced, from
the folks who do leanpub.com:

>   http://markua.com

in a related note, i have finished
my "beyond markdown" series...
>   https://medium.com/@bbirdiman/beyond-markdown-part-11-444393af1ed0

i put up a web-app as a playground.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

maybe we should discuss it

[bowerbird via Markdown-Discuss]

in terms of my last post here:

  

http://six.pairlist.net/pipermail/markdown-discuss/2014-October/003247.html

i was intrigued to see this today:


  https://thegrid.io


this mirrors earlier flipboard tech:
  

http://techcrunch.com/2014/03/23/layout-in-flipboard-for-web-and-windows/

-bowerbird

p.s.  by now, you might have figured out that
you can search twitter for "beyond markdown".

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

re: let us not discuss that here

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

re: let us not discuss that here

[bowerbird via Markdown-Discuss]

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

let us not discuss that here

[bowerbird via Markdown-Discuss]

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 a " > " on 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

money for mou

[bowerbird via Markdown-Discuss]

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

september is still the cruelest month

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

re: wysiwyg and light-markup are oil and water

[bowerbird via Markdown-Discuss]

mofo said:

  I do get a bit irked by the amount of screen re-estate it takes.


yeah, i suppose it depends on what you happen to be doing.

i do have some ideas i'm researching that riff on that thought.



  Perhaps we can drop the wysiwyg


well, i think it's interesting to think about these things, and to
discuss them, especially if anyone has ideas on all of this, so
i'd love to talk if y'all have wysiwyg solutions, but i have none. 
:+)




  and stick to input/output model
  but maybe with this twist:
  Place the input screen on the top,
  and the output screen on the bottom.
  Input takes vertically 20% of screen,
  and output takes vertically 80% of screen.


that's easy.

the html-demo-code i have put up uses "position:absolute",
so people can arrange the interface any way they want to...

i've also researched jquery drag-and-resize components,
for even more flexibility, but it's hard to say if it's worth it...



  A red 'box' in the output screen shows
  where the part that the input screen is showing.


some good code will sync input and output when you want.

-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

[bowerbird via Markdown-Discuss]

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

wysiwyg and light-markup are oil and water

[bowerbird via Markdown-Discuss]

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 basic gruber markdown basics

[bowerbird via Markdown-Discuss]

# THE GIST OF MARKDOWN'S FORMATTING SYNTAX

### an adaption from text by John Gruber







## 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 `` and `` 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



* Candy5
* Gum5
* Booze5



+ Candy6
+ Gum6
+ Booze6



- Candy7
- Gum7
- Booze7



* 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



1. Red4
2. Green4
3. Blue4


1. Red5
1. Green5
1. Blue5


9. Red6
9. Green6
9. Blue6



1. Red7
2. Green7
3. Blue7



1. Red8
1. Green8
1. Blue8



9. Red9
9. Green9
9. Blue9

If you put blank lines between items,
you'll get `` 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:

![alt text](http://zenmagiclove.com/simple/gruber-logo1.png "optional 
title")


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 `—`
instead of decimal-encoded entites like `—`.

I wish SmartyPants used named entities like
— instead of decimal-encoded
entites like —.

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

the trains are already leaving the station

[bowerbird via Markdown-Discuss]

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

[bowerbird via Markdown-Discuss]

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

on syndromes and naming and "promotion"

[bowerbird via Markdown-Discuss]

-- 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.

-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

[bowerbird via Markdown-Discuss]

 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
you will find yourself making great progress toward crystal clarity.
because you now have an infinitely better understanding than his.
after that, you can drag back the pieces of his model that still "fit".

all by itself, that will ensure your success.  but here's another tip:
if different flavor-developers made incompatible interpretations,
it's because they weren't operating with the same mental model,
so those incompatibilities are sign-posts to spots that need work.
and the work is _not_ in the simply resolution of a decision-fork,
but rather an understanding of how those developers ended up
in two separate places with different perspectives on that issue.
what led one to be on the east side, and the other on the west?
and how do you channel _users_ so they're all on the same side?

i've probably said too much, for my own good, and in your eyes,
but there it is.  best of luck down the line in the work you're doing.

-bowerbird

p.s.  andrei said:
>   Times without hardware specs mean nothing,
>   please also provide some hardware specs

times _with_ hardware specs mean next-to-nothing.
give me the code, so i can run it on my own machines,
on my own documents, so i can feel the speed myself.

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

clear model, clear sailing

[bowerbird via Markdown-Discuss]

ipe for inconsistencies which should be _avoided._

there is one model, which is developed as a dance between
developing specification and running code, and _that's_that._
once your model is done, so is your spec and pseudo-code.

you think this is hard because you are doing it wrong.

once you do it correctly, you'll see that it's very easy.

by the way, there is the silly idea running around that
there's some conflict between users and implementers.
this, too, is one terrible misconception.  once you have
a clear model, it's clear for users _and_ implementers.


>   if you want one or another Markdown flavor
>   to become the standard, you need to find a way
>   for its implementation to be included everywhere.

i couldn't care less about any markdown flavors.

i believe in light-markup.

and after being the best-friend to light-markup for a while,
in recent years markdown has turned into its worst enemy,
due to a downright refusal to recognize and correct flaws...


>   But with all the diverse language ecosystem we have,
>   and with the varied needs of different communities
>   using Markdown, that seems quite difficult to achieve.

it will be quite difficult for markdown to achieve that, yes.


>   I'd call that impossible.

maybe even "impossible".

but it's within reach for light-markup with a clear model.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

when rational discussion was still a possibility

[bowerbird via Markdown-Discuss]

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

let's chat about tables

[bowerbird via Markdown-Discuss]

yesterday, i understood the silence on this listserve fairly well.

after all, what can the ants really say when the elephants fight?

especially when the one group of elephants botched it so badly?

so very badly that all the other group of elephants has to do is to
call the first group "dicknose" and, ta-da, "mission accomplished".

so, you know, what are _you_ gonna say?  nada.  ergo, silence.

totally understandable.

but now you're busy rearranging the deck-chairs on the titanic?,
chattering away with almost a dozen messages about _tables_?

while the elephants are still fighting?  are you folks plumb crazy?

-bowerbird

p.s. i find it perplexing that people, including gruber, apparently,
think the plot was hatched on this listserve.  perhaps i missed it,
but when did jeff atwood _ever_ post a message here?  when?
other than macfarlane, none of the principals are regulars here,
and -- for all i know -- aren't even subscribed; why would they be?

p.p.s.  as you'd expect, the rest of the internet loves the dust-up.

metafilter:


  http://www.metafilter.com/142475/Standard-flavored-Markdown#5718950
  209 comments


hackernews:


  Standard Markdown
  https://news.ycombinator.com/item?id=8264733
  354 comments



  OMG Markdown
  https://news.ycombinator.com/item?id=8270771
  85 comments



  Standard Markdown Is Now Common Markdown
  https://news.ycombinator.com/item?id=8271327
  204 comments


reddit:

  

http://www.reddit.com/r/programming/comments/2fdsan/standard_flavored_markdown/

  261 comments


  

http://www.reddit.com/r/programming/comments/2fi4mh/standard_markdown_is_now_common_markdown/

  283 comments


but here? well, here, we're talking about _tables_.  ok...

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

september is the cruelest month

[bowerbird via Markdown-Discuss]

have you heard the breaking news?

>   http://standardmarkdown.com

ok. well, at least they all agree about the yankees.

who, but the way, "suffered another woeful defeat
on tuesday, falling to the last-place red sox, 9-4,
in the opener of their nine-game home stand."

the yankees are 5 games back for a wild-card slot,
with 6 teams involved in that race, meaning that
jeter might get no post-season play his final year.

 but at least there will be an apple announcement.

-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

[bowerbird via Markdown-Discuss]

# 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

now let's take another step forward

[bowerbird via Markdown-Discuss]

# now let's take another step forward


now that we've got something straightforward
put into place, let's see if we can stretch a bit.

first, though, let's do the error-correction thing.





## table of contents


autotoc





## bowerbird made a mistake, and apologizes


gerald said:

> There's no dependency on Ruby or Ruby on Rails.
> It's a static (server-less) single HTML page (w/ JS and CSS)

thanks for correcting my error in that regard.

***

gerald said:

> I guess it's my error -- will remove the
> real world case study (that mentions Ruby on Rails
> and might, thus, lead you to think you need Ruby

no, it was clearly my error, not yours, and i apologize.

indeed, if i unpack the .zip file containing your project,
and mount the entire thing, it works, as is seen here:

> http://zenmagiclove.com/misc/s/markdown-note-folder/note.html

whether you want to change your documentation or not
is a separate matter, and that decision will be up to you.

still, my mistake was my mistake.





## but something still misses the mark


however, something still misses the mark here, at least
in terms of my overall goal, so let's see if i can explain it.

the first thing i did was to summon up your demo page,
which, as you just announced, has now moved to here:

> http://writekit.github.io/markdown.note/note.html

then i saved the "page source" -- i.e., just the .html file.

but when i then loaded that saved file into the browser,
it didn't run. i had seen something about ruby-on-rails,
so i assumed -- incorrectly -- that that was the reason.
and i apologize for jumping to that incorrect conclusion.

but once you told me my error, i went back and looked,
and the .html file (which i'd saved) failed for me because
links pointing to the .css and .javascript files are relative.
so it wasn't ruby/rails that was absent, it was those files.

once i changed those links, it did work. you can now find
a version of the file as i have reworked it at this location:

> http://zenmagiclove.com/misc/s/MarkdownNoteNot-v3.html

i have copied this post into that file, as another example.

the file validates, but the browser says this file is missing:

> http://writekit.github.io/markdown.note/js/lib3rd/jquery-2.0.1.min.map

that's also a message the browser gives on your example.
something to do with the minimized jquery file, but it seems
to have no real effect on the successful running of the code,
so we can just ignore that. as long as it works, we're good.

i also do not grok textarea-in-a-table markup, so i wrote
a javascript routine that resizes the textareas and display.
(it uses a timer because it was quick-and-dirty, but that
is an operation that should be cued to open and resizing.)

so this file now works in a fashion near _what_ _i_ _want._
(and i hasten to add that i am not necessarily advocating
other people should want what i want; decide for yourself,
and decide differently for different needs at different times.)

that is, if i download this .html file -- solely by itself -- and
load it back in the browser, it runs and works successfully.
so that's very good, and gives me part of what i'm seeking.

however, it is still loading a bunch of files from the internet.
and it won't work correctly without downloading those files.
meaing an offline-only work-flow will neither work nor flow.

if i were to copy those .css and .js files to my own machine,
and were to restore the pointers so they were again relative,
i could run my .html file without having any internet access.
so that's even better. but now we are asking for a bit more,
compared to the simple saving of an .html file in the browser.

what i really want the most is to download just the .html file,
and have it work correctly, without requiring any other files.
which means bundling all those other files into the .html file.
that is certainly do-able, but it weighs in at 190k with jquery.
in an age of 1meg webpages, that's relatively lean, yes, but
it would be even better if we can take it down in size a little.

it is, however, a very cool feature that you have brought to
the table, with this ability to easily toggle many converters.
i can see that being extremely useful when one is trying to
track the nature of inconsistencies between different flavors.

(i did get "uri too big" error-messages from heroku when i
tried to use some of the ruby converters, i don't know why.)

finally, and i'm willing to concede that this might just be me,
but i don't like having to live in somebody else's .css world.
so when we are customizing and personalizing an interface,
the less .css a project brings as baggage, the better i like it,
and i'm never really happy until all of that baggage is gone.
not that you used a lot of .css, gerald, but there was some,
and even that wee bit was enough to make customi

what i meant by "simple"

[bowerbird via Markdown-Discuss]

# 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

simple sample side-by-side setup

[bowerbird via Markdown-Discuss]

# simple sample side-by-side setup

there are so many light-markup editing environments
out there these days that it takes a good deal of time
to evaluate which one might be right for you.
and even after you've done that, you might
wish some of its features were slightly different.

the good news is that it's relatively easy to set up
a side-by-side .html page. from there, you can
customize the environment to your own preferences.

here's some sample code that creates such a split-screen set-up:


http://zenmagiclove.com/misc/s/side-by-side.html


## the basic set-up

the left side is for editing the text,
and the right side is for displaying the .html.
as you would expect, as you edit,
the display on the right-side gets updated.

this is a simple javascript setup. it uses jquery at present;
you could make it independent, but the pageload burden
posed by jquery isn't really all that significant.

you'll notice that there are buttons along the top and bottom
of the page, which you can use for any functionality you might
want to incorporate. some of them are currently just
placeholders, labelled "npy", short for "not programmed yet".

at the top left is a button labeled "top". clicking this button
causes both the edit and display fields to scroll to the top.
you might or might not think that's handy enough that
you want to keep it.

on the right side, the "preview" side, the 3 buttons at the top
are labeled "display", "source", and "toggle".

* the "display" button shows the .html as it would appear on the page.

* the "source" button shows the .html in its "view source" mode.
(note that i have hacked the source a bit to make it more readable.)

* the "toggle" button toggles between the "display" and "source" views.

at the bottom left, on the text-editing side, is a button labeled 
"full";
clicking it will cause the edit-field to grow to full-screen; at that 
time,

the button's caption will change to "split". clicking it then will cause
the split-screen view to return.

at the bottom right is another button labeled "full",
which causes the .html side to go to full-screen,
when it too has a corresponding "split" mode.

this code creates a design that works well on an ipad,
and as good as could be expected even on an iphone.
but i claim absolutely no expertise at .html or .css, so i
would not be surprised in the slightest if it can be improved,
and i welcome all suggestions.

## customizing the experience

there are a myriad of features that you can add to such
an "editor", of course. and that's why we're doing this.
so let's explore some of the possibilities.

### where to save

the first necessity is the ability to save your updated text.
in various iterations of this model, i have saved text to a website
using a helper-app on the server (which is quite simple), and i have
saved to dropbox using their canned routines (which is not difficult).
if there is interest, i'd be willing to share those routines.

you can also save to local storage, just as long as you understand
the ramifications of doing that, the main one being that your text
is then available solely to that browser on that machine.

javascript will sooner or later be able to save to the file-system
proper, but don't hold your breath for that.

### which converter to use

another big question is which conversion routine you want to use.
a javascript routine, sitting right in the webpage, is going to be
the fastest solution. that's what i'm using here.

you can also send your input-text to an online converter,
and then display the resultant-html when you get it back.
not quite so fast, but not intolerably slow either, especially
if your text isn't huge and your connection is fast enough.
but not nearly as snappy as the javascript route.

the main advantages of a javascript routine is that it can be
bundled right inside the page, it's fast, and -- moreover --
it's customizable. just as you are customizing your "editor",
you can also customize your converter, so it does whatever you
want it to do. no need for pre-processing, or post-processing,
or living with somebody else's notion of "good markup".
when if you have a project which has some "special needs",
you can rewrite the converter to accomodate them. in the end,
you might well find this is the very best reason for choosing a
javascript converter. i know i won't use anything else these days.
i don't want to be stuck inside somebody else's box.

you'll find that that sample set-up actually bundles in two converters.
the first is the "marked" converter from chjj, the premiere javascript
conversion routine. the second is the javascript routine john macfarlane
just released. the "gwhichconverter" global controls which routine is 
used.



http://github.com/chjj/marked
http://github.com/jgm/stmd


this demonstrates another benefit of javascript converters, that you can
bundle in several of them, and switch between them on-the-fly if you 
like.


### when to save and convert

the next questions 

here are some opinions

[bowerbird]

here are some opinions; take 'em or leave 'em.

we might eventually have as many "standard"
editions of markdown as we now have flavors.
that should make things twice as fun as before.

***

any spec without an accompanying converter is
all talk and no action; the proof is in the pudding.

***

if you don't have a javascript conversion routine,
you do not have something that can be bundled
into an .html file, which is something you _need_.

and if you haven't ported your javascript converter,
to some other common language, you do not know
that it is robust enough for usage in the real world.

***

in this age of full-on markdown editing environments,
many open-source, a dingus is miserably insufficient.


  dillinger -- https://github.com/joemccann/dillinger
  stackedit -- https://github.com/benweet/stackedit
  gfmarkdown -- http://jbt.github.io/markdown-editor
  minimalist -- 

http://github.com/pioul/Minimalist-Online-Markdown-Editor

want more?  see

  http://mashable.com/2013/06/24/markdown-tools/

that list is a year old, but is still a fairly good inventory.

***

you also need an online converter with a friendly a.p.i.
this will create the canonical output for your converter.

***

nothing named "markdown" will avoid the tar-pit of
all the other flavors/editions also named "markdown".

anything _not_ named "markdown" will have difficulty
competing with the vague thing known as "markdown",
even if it is clearly equal or superior to all of the flavors.
because the blind men never did figure out the elephant.

this is a very fine mess which gruber has gotten us into.
thank goodness philly now brings to mind mo'ne davis.

***

anyone who says they support "markdown", _without_
specifying the exact converter they use, should be shot.

***

john macfarlane is one of the heroes of light-markup.

***

it will be fun to hear what fletcher has to say these days.

***

it will be fun to hear what gruber has to say these days.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

a good sign

[bowerbird]

another long thread. isn't that cute?

***

it's far too little _and_ much too late.
all of the horses have now escaped,
so it will do no good to close the gate.

***

i will take it as a good sign when the name
is intentionally, actively, and loudly rejected.

when a new name and an energized mission,
educated with a sense of the possibilities and
a full determination to avoid the old problems,
rises from a new community of engaged users,
committed to the creation of an entire toolchain
-- without any further delay, because, honestly,
we needed this _yesterday_ -- i will be happy,
because then light-markup can get on with it,
so we can all move on to more important stuff.

the kludge was fine for a while, but it has now
lived long past its prime, and needs to be killed.

frankly, if you don't know that we can do better,
get out of the way. just plain get out of the way.

***

on the other hand, it amuses me to think that
-- down the line, let's say in 15 years time --
the old people who "want to use what i know"
are insisting on markdown the way those same
people today are refusing to give up ms-word.

of course, i am also amused that some of you
seem to be showing the tendency even today!:+)

have a pleasant weekend!

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: How often do you use inline images? wrapper is really useful?

[bowerbird]

tom said:
>   I definitely do! Tell me more …
>   or point me at it, or something.

my stuff is in a bit of a jumble right now.

probably best to e-mail me, and tell me
exactly what your interests are, so i can
point you to the piece of my puzzle that
will be of the greatest interest to you now.

a big cut is if you wanna do development
or just use some system to make e-books.

i'm streamlining a process to explain it all,
and will have it within the next few weeks,
so if you'd prefer to wait for that, that's fine.

but i'm more than willing to help people now,
if you wanna get started right away; e-mail me.


nancy said:
>   Softcover looks like a dream-come-true. I hope.
>   Hope springs eternal, I think, as I finally
>   open up the terminal window. Sounds drastic.

do please note that softcover.io is a newcomer now.

if you want the proven player, choose leanup.com.


***

tom said:
>   StrapdownJS (for those unafraid of the CapsKey)
>   is just mind-boggling. I became an instant adopter.
>   Thanks for your insight (as always).

strapdown _is_ mind-boggling.

moreover, it's one of those things that is mind-boggling
precisely because it is _not_ mind-boggling, but instead
is quite straightforward, easy, and obvious.  in retrospect.

of course, in retrospect, _everything_ is obvious.

but yeah, i've been talking about serving light-markup
(rather than .html), and having the client-end convert it
for several years now, including here in these archives.

***

ali said:
>   One step ahead is probably browser adoption.
>   A firefox extension for this:
>   https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer/

well, yeah, having the browser-makers do this "voluntarily"
would be the best way to proceed, because that would give
the methodology reach and legitimacy, plus ensure its future.

and it's indeed what i have wished for in the past, because
-- weighed against the bloatware that browsers are today --
including the 20k-40k of code for a conversion routine is tiny.

and it'd solve the chicken/egg problem that nobody wants
to serve light-markup if the browser will not convert it, but
they won't put in a converter if nobody serves light-markup.

my thought: "if you would convert it, they would serve it."

but i think the browser-makers are reluctant to include such
a light-markup conversion routine themselves, because they
don't want to suffer the backlash from users who'd then realize
that much of the .html pain which has been heaped on us was
_totally_unnecessary_ and could have been _easily_avoided_.

"you mean we could have been serving light-markup all along?
well, gee, thanks for not telling us that, you sadistic bastards."

i mean, seriously, it's some kind of sick joke that we're forcing
humans to mark up text "for the computer", when the machine
can do mark-up a _lot_ faster and more efficiently than we can.

the machine is supposed to work for us, not make work for us.

but even once they _do_ finally decide to include a converter,
browser-makers have shown they move agonizingly slowly...

no matter...

because now that we've become comfortable with javascript
(albeit fairly uneasy and queasy, for many very good reasons),
we can include a conversion routine ourselves, along with our
light-markup original file, and have the client-machine run it...

so...

how does that javascript-converter-bundled-with-light-markup
approach differ from the firefox extension "markdown-viewer"?

well, in a few small ways, that end up being extremely important.

first off, you'll notice that i've been saying "light-markup", and
_not_ "markdown".  well... there's a very good reason for that.

and it boils down to the 3 million different flavors of markdown.

the nightmare is that the flavor of markdown which i am serving
is _not_ the same flavor that you have in your viewer-extension.
so the rendering is flawed, in ways neither you nor i might know.

and another nightmare is that there are 87 different extensions,
and they all use different flavors, so i'm now in a no-win position,
and thus no matter what flavor i serve, it'll crap out for someone.

(no sooner do i write this than tom points to other extensions.
yes, there are many of them out there, with more on the way.)

and note that this scenario will also hold if the browser-makers
include converter-routines themselves, but use different flavors;
that would be the absolute worst-case version of this nightmare.

as long as you are using markdown as your light-markup format,
the obvious resolution of this nightmare is to serve the converter
you've tested with, and thus _know_ treats your input correctly...

hopefully, when the world decides to go "all-in" on light-markup,
we will discard markdown and choose a non-fragmented format.
(i would ra

re: How often do you use inline images? wrapper is really useful?

[bowerbird]

deidre said:
>   XSL-FO + FOP
>   http://deirdre.net/making-book-a-technological-evolution/

interesting.


>   Nowadays, you can do it at the command line on a Mac

nowadays, markdown input to multiple e-book output formats
is basically a one-click process, and involves no terminal use.

i'm actively developing in this arena, if anyone wants information.

-bowerbird

p.s.  and if you want to sell your e-books, there's always leanpub,
as well as softcover.io, a brand-new entrant on the e-book scene.

p.p.s.  the coolest markdown-related shit out today is strapdownjs.

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: How often do you use inline images? wrapper is really useful?

[bowerbird]

alan said:
  I hadn't realized that XHTML was so important for e-book 

publishing.

the corporate publishers have tried to sabotage e-books since
the early days, so xhtml was meant to raise the difficulty-level,
one of many choices made to discourage self-publishers from
disrupting the space and disintermediating the gate-keepers...

as for validation, it's required by the online e-bookstores (except
when they choose to make exceptions for their own convenience),
but most of the viewer-programs don't enforce validation strictly...

of course, none of the viewer-programs do _anything_ consistently
-- including simple rendering of content in the manner specified --
so you might run into the occasional exception on this issue, sadly.

meanwhile, sensible people are formulating more sensible criteria,
so when the dinosaurs go extinct, we'll leave that nonsense behind.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: yet more harmful

[bowerbird]

christoph said:

  Thanks for that article, bowerbird,
  I found it quite entertaining.


you're welcome. i'm glad.

***

i wrote the "harmful" piece as my personal "goodbye",
to markdown in general, and this listserve in particular.

so i'll answer here, but let's not make it too protracted.
so, if you respond in any lengthy way, go backchannel.

**

christoph said:

  Fragmentation of Markdown specifications
  probably isn’t a great problem for most people
  because most texts are short-lived.

...

  Most texts are also short-form


this, all by itself, in a reverse-field sort of way,
touches deep and important issues that would
surely cause this thread to go entirely too long.

so let me just answer your points with a question:

"what is society's current solution as its file-format
for historical archive and re-use of its documents,
and how well is it now serving those dual purposes?"

***

christoph said:

  I would like to play with zml — however,
  have you even published an app or some script?


i've built, coded, researched, and recoded a whole system.
then tore it down and built it again.  and again and again.
then ported in to perl.  then rebuilt it again.  and again.
then ported it to python.  then javascript.  then rebuilt it.

i've got offline versions (cross-platform) and web-apps.
i've got server-side, a.p.i., client-side, and all-in-a-page.

i can load-and-save from local-storage, your hard-drive,
dropbox-and-5-other-cloud-services, or one of my sites.

i am now beginning a phased release of all these things.

i must confess that i am confused about how to do this,
but here is one of the initial thrusts toward that direction:

  

http://www.kickstarter.com/projects/bowerbird/jaguar-cub-a-simple-tool-for-great-e-books

i'd appreciate any feedback you have on any of that.
goes for anyone here.  if you wanna see stuff, ask me.

***

christoph said:

  I tend to disagree on your opinion on split screens
  for input and output. I find it very distracting
  to see what my text will be rendered as while I
  try to concentrate on its structure and content.


the preponderance of wysiwyg is an indication that
you're the one who's out of step with the mainstream.

but i understand your position, because i often share it.
most markdown users are comfortable without preview,
or they wouldn't be using markdown.

so i am not advocating a preview should be "required".
(as if we could even do that.)  especially on a first-draft.

still, terpstra's "marked" has proven a definite demand.



  Also, since I care a lot about typography, too


in a sense, that refutes what you just said right before.

unless the reason it is "very distracting" is _because_
you "care a lot about typography".  which i understand.

either way, you can just turn off the preview.

or -- better yet -- learn to ignore it selectively.

i've learned that the people who care about typography
generally care about it too much, and that they would be
good to let go of a little of it, for their sake, and for ours.



  seeing a — for the most part —
  preliminary and incomplete rendering
  of the final output immediately


i'm not sure why you think the rendering will be
"preliminary and incomplete".  you see some text
-- perhaps a couple paragraphs -- and their output.
and if the text doesn't change, the display is "final".

but yes, again, if your text is still in a jumble, then
a preview won't mean much.  so simply turn it off.



  makes me want to work on the displaying rules
  (CSS, in most cases). Where’s that different
  from fiddling with styles in Word etc.?


the system doesn't make it easy to fiddle with .css.

it only makes it easy to edit the text.  that's by design.

at some point, you have to develop the self-control.



  I do like the way some editors give me a hint of
  what the text will be like in the final output
  by way of syntax highlighting or semi-wysiwyg


i see you've made it to the half-way house in your
quest to reach the goal of full self-control.  good job!  :+)

half-way has always seemed half-assed to me, but
to each his own.



  à la Byword or Writer. What is your take on those?


my attention-span is too large for one line at a time. ;+)

heck, i don't even like the systems which require me
to chop up books into _chapters_.  too reductionistic.

but the world of writers is large and highly variegated.
i value the final product, not the way it was generated.
so as far as tools and processes go, i say it's all good.
if it works for you, _use_it;_ don't let anyone sway you.



  the bigger problem we face today is the _output_
  of electronic texts. A good looking Kindle book,
  for example, has yet to be shown to me.


i agree with you on the main point.

then again, almost everyone agree

re: more harmful

[bowerbird]

issues with markdown,
we'll also need to quickly acknowledge that
his time is his, to do whatever he likes, plus
his notes app has made him lots more money
than any markdown work would've paid him.
so society's message to him seems _clear_.


>   I like Gruber on daringfireball, personally.
>   I suspect he does too.

so do i.  it keeps him out of trouble.;+)


>   Yeah, true. 

truth is a fantastic destination to arrive at.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

markdown considered harmful

[bowerbird]

i don't talk about people behind their back.

>https://medium.com/the-future-of-publishing/495ccfe24a52

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

a little higher complexity

[bowerbird]

>   even if it's at the expense of a little higher complexity

kinda silly, it seems to me, to talk either way about
the costs and benefits of "a little higher complexity"
when you're already six layers deep under the crap.

blind men, trying hard to describe the elephant's ear.

look at the pandoc/babelmark documentation of the
inconsistencies across the different flavors, and then,
if you can find a way to straddle all of _that_ difficulty,
you might have some chance of writing up a document
that will actually be of good use to a number of people.

of course, if you can really sort through that ugly thicket,
then your talent could be put to much better use, solving
the trouble in the middle east, or even the u.s. congress.

-bowerbird

p.s.  of course, if this is merely one nifty mental exercise,
because jigsaw puzzles are too boring, then by all means,
have at it, with my best wishes, and forgive the intrusion...

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

that ship has sailed, and those islands are under water

[bowerbird]

michel said:
>   I find it hard to do anything in PHP Markdown
>   without somewhat worrying that it might
>   conflict with something else already in use.

you're worried about breaking markdown now?

um, gee, michel, i'm sorry to have to inform you, but
markdown has been broken for a very long time now.

so long that a new breed of freedom has emerged...

people can now do anything they like with markdown,
precisely because it _Is_ already broken, irretrievably,
so nobody has to ever worry again about "breaking" it.

that ship has sailed, and those islands are under water.

-bowerbird

p.s. speaking of islands under water and ships sailing,
even as the wackos continue denying climate-change,
the people of the marshall islands are packing to leave
the place which has been home to them for millennia.
ironically, while suffering the constant of the rising sea
and sad surprise from storm surges, the islanders also
just experienced a drought, causing food crop failures
as well as a critical shortage of drinking water which led
to severe problems with diarrhea and flu-ish symptoms,
compounding issues of abandonment and depression.
just in case you thought that _your_ problems are bad.

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: newbie seeks repo for markdown

[bowerbird]

don said:
>   at this time the classic markdown meets my needs.

are you using "classic" markdown?  or kramdown?

kramdown is a great flavor.  know what you're using.


>   i was looking for advice on how best to install it on a mac.

and you got some advice.  on how to install kramdown.

you could've gotten advice on installing multimarkdown.

>   http://fletcherpenney.net/multimarkdown/download/

or there are lots of other flavors.  none is hard to install.


>   advanced features are less important than
>   having a reliable automated installation procedure.

maybe i confused you, talking about "advanced" features.

look at this page and you'll see that many of the options
kramdown offers can't really be called "advanced" today.

>   http://kramdown.rubyforge.org/options.html

to start with the top one, header id's are "standard" today,
so markdown-converters are expected to generate them.

(most especially since such id's will not cause any issues;
after all, it's not as if you're _required_ to use them at all;
but if they aren't created at all, then you _can't_ use 'em.
maybe more to the point, nor can people who link to you.)

and gruber's "classic" markdown does not generate id's.

of course, what you will probably discover, quickly, is that
the header id's generated by one flavor don't match those
which are generated by another flavor, which means that
you're going to encounter problems when you collaborate
with another person (or yourself, at a future point in time).

so even if your needs are indeed being serviced _now_,
you are likely to find there will be glitches down the line.

or hey, maybe not.  return in 3 years if you wanna debate.

-bowerbird

p.s. but, bottom line, kramdown is as good as any flavor.

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: newbie seeks repo for markdown

[bowerbird]

don said:
>   i am looking for advice regarding the best repo

first you have to decide what "flavor" of markdown
you will want to be using. it sounds like you want
gruber's original, but i'd recommend against that,
because you will find it deficient and contradictory.
which is why people have made different flavors.

i'd recommend using "multimarkdown", because it
is one of the most highly-functional variants _plus_
then you can also use "multimarkdown composer",
fletcher's mac text-editing app with live conversion.

>   http://fletcherpenney.net
>   http://multimarkdown.com

"multimarkdown composer" also lets you "fall back"
to gruber's original markdown, if you really want to.

***

if you choose to use another flavor of markdown,
for some reason, or even with multimarkdown too,
i also highly recommend brett terpstra's "marked".

>   http://markedapp.com

like "multimarkdown composer", "marked" offers live
conversion-and-display as you edit a file, operating
_in_tandem_with_ your editor (whatever it might be),
by re-reading your file as input whenever it is saved.

so "marked" works with every editor, and any flavor.

indeed, you can even use it with restructured-text,
ascii-doc, textile, or any other light-markup format.

and this great versatility only costs 4 stinking bucks.
(in contrast, "composer" is a relatively pricey _$12_,
but you can keep in mind that it often goes on sale.)

there are other great markdown-related mac apps,
including "texts", "textastic", "mou", and many more,
most of them so inexpensive that you will not regret
buying them to throw a few bucks to the developers
for continuing to raise the bar in this active arena...

but to pick the top 2, it's "composer" and "marked".

-bowerbird

p.s.  i see you got a two-line answer while i was busy
writing this much longer response, but as it might help
someone with a broader question, i will post it anyway.

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

what this has to do with markdown

[bowerbird]

 in the air.
(like you just don't care. hu-hum, hu-hum, baby-cakes.)

i mean, i understand the paralysis that _will_ result when
you're mired in a standoff situation, like this has become,
but i think you markdown developers need to fight that.
instead, you've all let yourself become complacent about
the edge-cases and inconsistencies that dog the format.

a little elbow-grease might go a long way, is what i say.

but you're going to have to apply it.  i had to work a lot
to come to the easy understanding of intraword italics
that i have just imparted to you.  you need to work too.

and, for me, the italics situation was actually less sticky
than the asterisk problem, because asterisk-overload is
much, much worse.  asterisks -- which i use for *bold*
(and i didn't take the easy way out and require two) --
_also_ represent bullets in unordered lists, _and_ occur
in equations where they are the sign for multiplication.
writing the routines to sort through all that was a pain.

further, curly-quote conversion isn't as easy as it seems.
a single round of thinking (like microsoft did) will create
a converter that makes some very embarassing mistakes.

even a couple more rounds of thinking might not give
you a routine that correctly gives straight-quotes in the
cases where the marks are referring to feet and inches,
or the minutes-and-seconds part of lattitude/longitude.

again, this is the kind of intense thinking you have to do
if you wanna sort through these types of difficulties, but
nobody here that i can see is doing much thinking at all.
and for sure you don't share any thinking you are doing,
or bounce ideas off of each other in a collaborative way.

and that's really sad.

***

so, anyway, this is what i'd recommend for markdown,
as your general solution to the underbar/italic problem.

(and, yes, i am chuckling as i write this, because i know
darn well that nobody even wants "a general solution",
and even though some implementations already do it,
the rest -- including gruber -- will never, ever, follow,
so any such proposal is an exercise in mere folly, but...)

anyway, here it is:

ban intraword italics, outright, with full notice, _but_
make it clear that the workaround is to use raw .html
to obtain the necessary italics for any intraword needs.

(and if you're curious why i don't use this in my system,
the reason is because i do not permit raw .html at all.)

***

and, finally, hey, let's put this all into perspective, ok?

the kind of standoff we have here is relatively minor.
and the problems we see border on the most trivial...

we see the same type of stubborness at a larger level
as the big corporations continue lobbying for d.r.m.,
and the big tech companies up their lock-in tactics.

and unlike here, in little old markdown land, where
there is no money to be made one way or the other,
the dollars from d.r.m. and lock-in could be _huge_.
so those companies are gonna be firm, intransigent,
and persistent in their stubbornness and their greed.

and, on a bigger level still, look at global warming,
and the way that we are rapidly polluting our planet.

again, the standoff there is so much more dangerous,
as the money is _staggering_, so don't even bother to
wonder if any of the big corporations will ever change.

and once humans go extinct, it will not really matter if,
once upon a time, somewhere along the line, someone
had their italics messed up because of a stray underbar.

so, just so you know, if it was _just_ markdown that this
was relevant to, i probably wouldn't care nearly so much.

but the problem of stubborn standoffs is much bigger,
and applies to arenas far larger than this little molehill,
causing problems worse than the smell of dead skunks,
and _that_ is why i care, and why i choose to speak up...

now i will ask you: why do you sit and suffer in silence?

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

fan_fucking_tastic

[bowerbird]

fan_fucking_tastic.

somebody hit another one of the dead skunks on this road.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: dead skunk in the middle of the road

[bowerbird]

tom said:

  I was a bit disappointed when this little posting didn't rhyme.
  With apologies to the author, I've touched it up a bit:


no apologies necessary, tom.  you've done an extremely fine job!

except for those ugly uppercase letters, i accept all of your edits.  
:+)


-bowerbird

p.s.  ok, i'd rather have "every" spelled-out, but that's a little 
quibble,
and i don't intend to look this gift-horse in the mouth any further...  
  ;+)


p.p.s.  as the old saying goes: "i didn't have time, to make it rhyme."

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

dead skunk in the middle of the road

[bowerbird]

well yes, it's easy enough to go around
a dead skunk in the middle of the road,
once you know that the thing is there...

the problem is that all of the new drivers
on this increasingly heavily traveled road
hit the darn corpse, over and over again,
and the smell just gets worse and worse.

but none of the people on the road crew
seem to want to move it off of the road...

"just drive around it", they say.  yeah, right.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

the will of the people

[bowerbird]

sherwood said:
>   Several people have spoken eloquently that
>   this is a Bad Thing (tm) and no one has agreed.
>   I must abide by the Will of the People, and
>   withdraw to the Cave of the Curmudgeons.

we don't yet know the will of the people, sherwood.

because "the people" generally do not even realize
there is a problem with markdown fractionalization.

all we have, thus far, are markdown _developers_
who continue to assert that "there isn't a problem"
-- over and above what michel terms "edge cases"
and "extensions to the core syntax" -- as if those
"extensions" weren't absolutely necessary so as to
overcome the primitive nature of "the core syntax".

but when "the people" come to learn the reality of
the inconsistencies that will break their documents,
they will squawk loudly, and we'll know their "will"...

you can hear the beginning of the rumbling already,
from the techies who are using markdown, and are
-- as a result of that normal usage -- thus becoming
aware of the problems once their users go past the
superficial nature of the 10-minute markdown intro.

ergo, outcry from stack-overflow and github people.

or lately, in the past week, this post on hacker news:
>   https://news.ycombinator.com/item?id=5613841

it's easy to get people to fall for something "simple"
when they think that simple is all they'll ever need...

but once your "simple" bites them in the butt, badly,
they'll see it was a mistake to jump in the quicksand.

as markdown continues to become more prevalent,
the dissatisfaction it generates will grow alongside.

and it was all so easy to predict.  and thus sidestep.
but nobody took straightforward action to prevent it.

-bowerbird

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

the problem is intractable, and perhaps insoluble

[Bowerbird]

my sincere and embarrassed apologies for that message just now
-- which was supposed to go to the project gutenberg listserve...

if someone has the ability to delete it (and this), i would request and
appreciate that action.   once again, my humble apology for my error.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

the problem is intractable, and perhaps insoluble

[Bowerbird]

i'm not sure why i work so hard to be accurate and fair
when i'm discussing jim, when he in turn seems happy
to engage in innuendo and outright _lies_ to slime me.

some of the things he says are flat out 360-degree lies,
so he obviously cares not even a whit for his credibility.

which is why i feel no need any more to counter his crap.

because once you've cleared away his smoke-screen and
wiped off all of the mud he threw, it's transparently clear
that jim hasn't done the thought to have any real answers.

so it's a good thing nobody expects any answers from jim.

***

on the other hand, people _do_ expect (or at least _hope_)
that greg will have some real answers.   alas, it seems not...

this latest "solution" won't work, because it doesn't address
the intractable nature of the problem that underlies all this.

let's use #76 to focus our thinking.

what we need to do to have any "success" here is to actively
discourage users from downloading #76 for _any_ reason...

ideally, we would like to drive its download-count to _zero_.

(in a perfect world, we would also issue an apology for #76,
alongside a promise that we would never fail so badly again;
but for the sake of this post, let's just settle for "ideally", ok?)

any kind of "note" on the download page will be meaningless,
for the most part, because few people will bother to read it...

so the download-count likely will not be appreciably changed.
and if that's what turns out to be the result, that was a failure.

but let's say the download-count _does_ decline, significantly.

in some sense, yes sir, that outcome would be "a success"...

but what it'll also do is engage david widger in a new battle.
(and by "david widger", i mean the whitewashers as a group.)

once the whitewashers got wind of greg's "experiment" at the
start of the year, they scrapped it, and slapped marcello down.

the outcome here would be the same, but even more extreme.

it's easy for us to sit on the sidelines and declare e-texts to be
"lacking in quality", but the whitewashers were the gatekeepers
who passed through every single one of them as "acceptable"...

meaning that the issue is not _just_ with those e-texts which
were digitized by a whitewasher, but every book in the library.

the whitewashers have the power of control when it comes to
deciding what _is_ and _is_not_ "acceptable" for a p.g. e-text.

and the whitewashers are long-accustomed to rejecting -- and
even ignoring totally -- all criticisms of their curatorial efforts.

***

so the crux of the issue revolves around the download-count.

either it stays up for #76, in which case it means that you have
_not_ solved the problem, or else it goes down, in which case
you've created a poisonous engagement vs. the whitewashers.

you might win that battle, but you'll lose the war when those
whitewashers walk away and you have to try to replace them.

and even the seemingly non-problemmatic course of action --
having david correct #76 -- isn't the panacea it promises to be.

first, it's not all that easy to fix a text, not in their current state
(namely, rewrapped, and rarely attached to a specific scan-set).
and i'm referring here to _everyone_, not just the whitewashers.
jim, for instance, has a hundred+ errors in his version of "huck".
karen lofstrum had several hundred errors in the book she did.
so even those rock-throwers have targets on their _own_ backs.

second, and perhaps more important, it would force david to
admit his work on "huck" -- which has stood for a _decade_ --
is substandard.   he's gonna stonewall you on that contention.
because as long as he can resist you on an example that bad,
he knows he can resist you totally.   he _also_ knows that once
he's defeated on worst-case, it's slippery-slope on all the rest.

and thus, the problem is intractable, perhaps even insoluble...

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

no.

[Bowerbird]

aristotle pagaltzis said:
>No.

i'd say that sums up this entire listserve in one word.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

a new acceptance of a variety of (inconsistent) markdown implementations

[Bowerbird]

babelmark sure does make it easy to convince people
that markdown inconsistencies are a mess of trouble.
before, people ignored the problem and/or its scope.

and waylan's new list just shows how big that mess is.
especially if we acknowledge all the other uses extant.

plus gruber's latest manifestation of his longstanding
reluctance to "fuck with it" means markdown is stuck.

so, i wonder if we've now come to a new acceptance of
a variety of (inconsistent) markdown implementations?

not that any of the urges to resolve the inconsistencies
ever attained anything more than a passing interest...

but still, i would think if the idea of unifying markdown
is officially dead, then that is the beginning of the end
for markdown itself.   as a house divided against itself...

i know that, as a possible "competitor" to markdown,
(at least in your eyes; in mine, we're all light-markup),
one who was planning on a nanowrimo push anyway,
i feel a new source of vitality for a niche opening up.

since babelmark sure makes it easy to go negative...

-bowerbird

p.s.   it _is_ ironic that the eve of "the day of the dead"
seemed to be the appropriate time to make this post.___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

the future of markdown, according to whom?

[Bowerbird]

i am waiting to hear about "the future of markdown"
according to john gruber, because as far as i can see,
he's the only person who can determine that future...

sadly, however, i think i _did_ hear about it from him,
in that "i'm not gonna fuck with it" post from last week.

i know i'm certainly not _expecting_ any more from him.
he's met his one-post-every-two-years quota for now...

besides, i'm not sure anyone _can_ update markdown,
not at this point, not even the mighty gruber himself.

there are so many renegade developers who are now
using the label "markdown" to mean "i will automate
your italics markup, but _little_else_" that the term is
next-to-meaningless in any kind of structured form.
those kids ain't gonna march in strict compliance with
any new rules and regulations that you might require.

as for a new name -- be it "rockdown" or whatever --
that's just gonna fragment things even _more_ badly.

i mean, it will help you to isolate those rebel kids, but
at the same time, you might be surprised to learn that
they constitute _much_ of the "uptake" gruber admires,
so if your main intent is to draft on his success so far,
you will find yourself with less oomph than you hoped.

(by the way, in case it isn't clear, i'd say that gruber is
overestimating the value of markdown's uptake so far,
given that so much of it does indeed reside in those
half-assed -- or quarter-assed -- implementations.
if such trivialities are what "markdown" really means,
then you can have it.   of course, for his blog anyway,
trivialities are how gruber uses markdown, if he does.
have you done a view-source on daring fireball lately?
john is using definition-list tags for his blog entries!
hey, i've never been one to argue for "semantic purity",
so i don't care, but who wants to use that as a model?)

in other words, i think it's too late to "unify" markdown.

and that's even assuming that y'all are able to _agree_
how to resolve the inconsistencies, which is doubtful...

which means that it's _really_ too late.   far too late.

and that's even more true if the effort is led by people
like atwood and/or greenspan.   they are highly skilled,
to be sure, and deserve kudos for calling out the need,
but this kind of thing needs to be headed by someone
like john macfarlane (who knows the issues down cold)
or fletcher penny (who has built the better mousetrap).
nobody else has the _gravitas,_ in my humble opinion.

but seriously, even with that, i still think it's too late.

and even if it's not, there is some question (in my mind)
whether markdown even _deserves_ to be saved.   really.

markdown is a sloppy implementation (by john gruber)
of a great idea (which predates gruber by many years)...
i think you can do much better.   i think i've done better.
take the key objectives, and make them even _sharper_.

maybe i'll write up some specific advice for you later.

or maybe i won't. (since some of you seem to dislike it,
quite intensely, whenever i do that.   which might just be
a good reason why i actually _should_ do it, let me see.)

but whatever i do, _you_ should seriously reconsider it
when anyone says they "just want to get back to gruber
had in mind at the outset".   because you can do better.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

the future of markdown, according to jeff atwood (and/or david greenspan)

[Bowerbird]

like history, the future is decided by the people who write it...

>http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html

by the way, if you want a form of light-markup which is
still flexible enough to be molded, but will be _totally_
free of ambiguities and "edge-cases", and governed by
a well-written specification and thorough documentation,
along with an exhaustive test-suite (in a single document,
rather than spread across a ton of little single-issue files),
which is easy for completely naive end-users to grok fully,
and even easier for competent programmers to code for,
although there's little need, since the system's logic exists 
both in pseudo-code and routines for several languages...

well, if that's what you're looking for, i have a contender...

>http://zenmagiclove.com/september.html

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

canonical

[Bowerbird]

john gruber said:
>The canonical docs are those on Daring Fireball. 

boom.   and there you have it, folks.   game on!:+)

-bowerbird

p.s.   y'all might wanna consider, however, that because
the yankees just got _swept_, it might be the case that
mr. gruber is merely feeling a bit...   "cranky" right now.___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: very impressive

[Bowerbird]

my fault.   somewhere along the line, i lost the "l" in ".html"...

but ".htm" is also "legal", so you'd think github should grok it.

maybe with that $100million they scored recently, they can
write an apache mod_rewrite rule...   woulda saved us a few
listserve posts, just in this one instance we had here today.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

very impressive

[Bowerbird]

jquery table editor in .html:

>http://warpech.github.com/jquery-handsontable/index.htm

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: A better guide to Markdown

[Bowerbird]

mikkel bang said:
>Is there a simpler, better designed guide to Markdown

so, are you the snowboarder?

for what purpose are you using markdown?

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Is there anyone would like to hold a standard organization of Markdown syntax?

[Bowerbird]

one of my conclusions in my long post was that 
"markdown standardization ain't gonna happen".

as i read fletcher, he came to the same conclusion
in his long post, for pretty much the same reasons.

honestly, if it was gonna happen, it already woulda.
requests will persist, and might well even increase,
but the catatonia has hardened, and is full-on now.
so the primary purpose of this listserve has become
for markdown developers to ignore markdown users.
the markdown listserve is dead; long live the listserve.

i also discussed how markdown could've prevented
its present situation, but that's an exercise that calls
for demonstration in the real world, not "discussion";
so i will set out to provide the proof in that pudding...

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: Is there anyone would like to hold a standard organization of Markdown syntax?

[Bowerbird]

i did write a long post in response to this thread...

but i guess it's best to just let this listserve wither.

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

ultimate markdown editor wishlistbowerbirdd

[Bowerbird]

i should probably just let this listserve die, but...

***

anyway, it's that brett terpstra fellow again...

>http://brettterpstra.com/my-ultimate-markdown-editor-wishlist/

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: a blade of grass cracks the sidewalk

[Bowerbird]

alan said:
>Congrats on shipping a nice dingus, Bowerbird.

i'm hoping someone with design chops takes pity on me,
and contributes something that looks significantly better.
but at base, it's just a 2-pane tool, so that's what matters.


>It does indeed look like 
>an extremely clean and powerful syntax.

that's what i was aiming at, yes.   easy to understand,
as a naive user, and easy to handle, as a programmer.
delivering great functionality while remaining simple.


>What causes the entire first page to be in bold? 
>Convention? 

mostly convention, yes.

the target is books, so the first section/page is defined as
the cover/title-page, which is traditionally centered bold.

but where there is a lot of text, such as on the example,
bold may be overkill, so that's something i might change.

i've been closely examining books for several decades now,
so i have a very firm idea about what my starting place is...
but i'm also quite flexible to the ways authors and readers
want to shape e-books to fulfill their destiny, which means
i am going to be quite attentive to the feedback they give...

i don't anticipate that _a_lot_ will change, but _everything_
is up for questioning; nothing is too sacred to be touched.


>Styles applied after your transformation to HTML? 

i'm not quite sure what you're asking.

there isn't a whole lot of styling going on, as you'll see
if you view source.   it's intentionally quite barren, since
the e-book viewer-programs today ignore most styling,
and substitute in their own, so it's best to just surrender.

another consideration is that my philosophical bent is that
it's the reader who should set many of the styling options.
so my viewer-program will allow the reader to customize.
part of the preparation for that is to get authors used to
the notion that they no longer control the look-and-feel.
(especially not with a tool that does the grunge for them.)

so it's a combination of both practical and philosophical.

having said all of that, the styling process is one of those
things on which i'll be actively soliciting input from users.

also, for instance, it would certainly be possible to offer
authors the option of using their own c.s.s. stylesheet...

and even if i didn't offer them that, it's not like they can't
simply edit the .html output before they go public with it.

what i haven't shown yet is that the .html gets wrapped up
into an .epub, and a .mobi, and a .pdf is created as well...
but you also get the .html files that build the .epub/.mobi.
(the 4, x, and 5 buttons display the various .html outputs.
right now, they're virtually identical; but they could fork.)

-bowerbird

p.s.   and yes, to all you haters whose mouths are frothing...
if this conversation persists for long, we'll take it elsewhere.
but if it makes you feel better, please post your rant anyway.___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

a blade of grass cracks the sidewalk

[Bowerbird]

spring has sprung, so on this day of grass,
i guess i just can't hold this back any more.

>http://zenmagiclove.com/aarp2.py

voila.   a dingus for zen markup language.

lighter than markdown.
_and_ more powerful...
i know.   wha?   go figure.

not that it's a competition.

supporters will love finally seeing a look.
detractors will love the bugs i left in there,
just for them, as easter eggs in the grass...

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

where are the worthwhile markdown dingi?

[Bowerbird]

lou said:
>$ kramdown test.txt > index.html; heel 

sorry, but by "dingus", i meant a tool located on a web-page;
one that takes text as input, and converts it to .html output...

something like this:
>http://daringfireball.net/projects/markdown/dingus

or this:
>http://michelf.com/projects/php-markdown/dingus

or this:
>http://fountain.io/dingus

or this, for restructured-text:
>http://rst2a.com/create/type
>http://rst2a.com/create/file

if there are other worthwhile ones, please let me know.   thanks.

-bowerbird

p.s.   "fountain" is interesting.   as http://fountain.io/faq puts it:
>Fountain is not an app. 
>It's not even really a file format. 
>It's a simple set of straightforward rules 
>for writing a screenplay in plain text.___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

where are the worthwhile markdown dingi?

[Bowerbird]

where are the worthwhile markdown dingi?   (dinguses?)

i'm interested in any dingus that can take a "reasonable"
amount of text -- let's say anything up to a megabyte --
and return the results in real-time, without a long wait...

ideally it'd handle something more than gruber-minimum,
and an a.p.i. (that'd take a u.r.i. as input) would be dandy...
bonus points for additional output (i.e., .epub, .mobi, .pdf).

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

yet another markdown text-editing tool

[Bowerbird]

"interesting" to see gruber mention yet
another markdown text-editor program
-- this one with just a little gimmick --
when he has never even acknowledged
on his blog fletcher's far-superior app...

gruber really does hate multimarkdown!

-bowerbird___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss