Text reflow woes (or: I want bullets back!)y

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> Here's a question which is going to sound aggressive or confrontational
> but is actually just me trying to help all of us (myself included)
> clarify our thinking and start moving in the direction of a deicision:
> 
> *ahem*
> 
> Given that, thanks to the inclusion of MIME types in the response
> header, Gemini is already perfectly capable of serving of Markdown, and
> given that Markdown is powerful enough to completely replicate all of
> the semantics currently in the text/gemini spec (i.e. it can link to
> other places via URL with a user-friendly label attached), what do we
> actually stand to gain by speccing text/gemini up as something which is,
> roughly, just Markdown with perhaps a few features removed and its
> native linking syntax replaced by our own line-based => alternative?
> Isn't this line of thought just leading us in the direction of
> substantial duplication of effort and having two redundant ways to do
> more or less the same thing?  Isn't that, generally speaking, a pretty
> bad way to design things?

  I thought that one of the overriding concepts for Gemini was the ease if
implementation---that one should be able to write a client in 100 lines of
<insert language here>.

  Now it has certainly grown a bit.  Given that a gemini index file can have
relative links:

	=> subinfo/document.txt	Some Text

means that clients now have to merge the base URL with the relative URL to
derive the new full URL complicates the client a bit, but we do get a lot of
functionality for giving up on ease of implementation (or the reliance upon
some libraries).

> If the answer to "what do we actually stand to gain?" is "Hmm, not much,
> actually" then it seems sensible to me that we should back away from
> this direction.
> 
> If the answer is "We gain X, Y and Z", then the syntax, then we can do
> our best to design syntax which maximises X, Y and Z.
> 
> Either answer clarifies things for us.

  The issue I have with Markdown is that there is no one standard for it. 
Mark Gruber created it in 2004 as a way for *him* to create HTML documents
without having to write HTML (or use a clumsy HTML editor) and he had no
desire to add to it (because it works for him).  Since then, multiple
versions have been created to address shortcomings people came across as
they tried using Markdown for their own use, and as of right now, defined in
RFC-7763 and RFC-7764, are the various flavors of Markdown:

	Original	http://daringfireball.net/projects/markdown/
	MultiMarkdown	http://fletcher.github.io/MultiMarkdown-4/syntax
	Github		https://help.github.com/articles/github-flavored-markdown/
	Pandoc		http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown
	Fountain	http://fountain.io/syntax
	CommonMark	http://spec.commonmark.org/
	kramdown-rfc2629 https://github.com/cabo/kramdown-rfc2629
	rfc7328		https://github.com/miekg/pandoc2rfc
	Extra		https://michelf.ca/projects/php-markdown/extra/

  It's almost like "pick your poison" here.

  -spc