Markdown and Gemini

[Brian Evans]

Tomasino writes:
> I am not much interested in forcing a markup format into Gemini at all.
> You have established a line-based hyperlinking that fixes some issues we
> faced in gopher. We have security in the protocol itself. As we start
> talking about the rendering of text we're getting away from heart
> described in the FAQ.
>
> I've been a voice behind the discussion of whether to reflow or not, but
> even that I'll admit goes a bit further than necessary. You're right
> about the MIME in the response header. Let Gemini stay simple. End the
> spec there and let clients decide what to do with the markup, if it's
> used at all. In another year the markup of the masses may change. We
> don't need to bundle that into Gemini from the beginning.

I both agree and disagree with the above sentiment. I agree the basic
gemini file structure that has already been preliminarily approved does
solve many of the issues people find with gopher (at least when combined
with the response header/mime). I like this fine and am still happy to
move forward with it (though some minor markup would be neat).

With regard to markdown files specifically, I do agree that it is out the
very outer edges of relevance to gemini as a spec. However, I do think
that if something like this is going to have an official integration into
gemini that it is best to do it with intent and figure it out early.

I had written a lot more here in support of markdown... but the more
I thought about it the more it felt like a separate concern. It might be
a good idea for a few developers that are planning on making feature
rich clients get together and try to standardise on some form of
markdown support so that a community standard can arise without 
the need of it being included in the gemini spec itself. If things went
that way I would advocate for keeping the gemini file format (with
the line based links) so that simple clients can still be built. 

Jason writes:
> 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.

If we go the route of markdown in either an official capacity or as
a community supported standard I would be happy to work on
getting a go module customized for this purpose... however, I just
looked and it seems that this would already do the job:
https://godoc.org/github.com/gomarkdown/markdown/ast


--?
Sent with https://mailfence.com
Secure and private email