Markdown and Gemini

[Jason McBrayer]

Brian Evans writes:

> I agree with Sean that the lack of a standard is an issue. Additionally, most
> versions of markdown allow for embedded html as well as inline images. I
> believe the majority of us were against these things. In additional to
> philosophical disagreements there are issues, as Sean also writes, with
> the mandate that a simple client should be buildable as a weekend project.

I have, from the beginning, thought that Markdown was the ideal document
type to serve over Gemini – it meets with my intuitions about "the Lynx
web" being about the right level of presentation complexity. I have been
supporting the use of Text Junior only because it is easier to implement
without library support than Markdown.

Can we talk about what we would want to restrict, were we to implement
Markdown in Gemini clients, and why?

1. No embedded HTML.

   This should be pretty obvious; we are not generating HTML, and we do
   not want to be supporting arbitrary HTML in the client, so there is
   no use-case for including embedded HTML. We should probably specify a
   behavior for embedded HTML that is included by mistake. Options are
   to strip it entirely, to extract text from it and put the text  in a
   paragraph, or to display it raw in a ```code``` block.

2. No inline images.

   There are basically two reasons. The less compelling reason to me is
   aesthetic: we want documents to be text, and inline images in NCSA
   Mosaic were the start of the slippery slope that led to the current
   web being mostly Not Text. I consider this less compelling, because
   there is a legitimate use for inline images as figures in academic
   papers or lead images in news stories, for example.

   The more compelling case, to me, is request predictability and
   tracking avoidance.  I want following a link in a Gemini client to
   make one (1) Gemini request and receive one (1) Gemini response.
   Inline images mean that a client may make a cascade of additional
   requests for resources that is not predictable by following the
   original link. Some of these requests may be to third-party servers,
   enabling tracking. This is something we strongly want to avoid.

The remaining reason to not use Markdown is client complexity. A simple
text-mode client can basically ignore *most* of Markdown's formatting,
and just display it literally. This adds no client complexity. The one
thing that can't be ignored is links, and Markdown links are somewhat
complex. They can appear anywhere in the text, and they can be in either
[immediate](gemini://domain/path) or [reference][1] format. This is an
impediment to easy implementation and I think is the biggest block to us
adopting Markdown for Gemini.

[1]: gemini://domain/path

> If that route were chosen, I think we would need to create parsers
> that return an AST in a variety of languages and make the libraries
> available to developers to use in their gemini projects. This would be
> a pretty big undertaking and I do not know that it is exactly in
> scope.

I am willing to write such libraries for Python and Common Lisp. The
existing libraries for both languages can be extended to provide
alternative outputs. The Python library uses ElementTree internally, and
a method could be added that uses the rest of the markdown library but
returns an ElementTree rather than a string. The Common Lisp library can
probably only produce a string (I will have to look at it further), but
that string could easily be an s-expression representing a parse tree,
so that's not hard to bring back into memory.

There is already such a library for C (discount)[2], though I don't know
what the in-memory representation is. I am willing to wrap the C library
for Vala, probably.

[2]: http://www.pell.portland.or.us/~orc/Code/discount/

--
Jason McBrayer      | “Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.”
                    | ― Robert W. Chambers,The King in Yellow