[Tech][Idea]Link syntax

[Philip Linde]

I accidentally sent this to just Robert, but it contains some
observations that I think are interesting to others in the thread.

On 7/28/21, Rev. Fr. Robert Bower <frrobert at frrobert.com> wrote:
> This is an idea I have pondered for awhile and the deurbanizing thread got
> me thinking about it again.
>
> Gemini document syntax in many ways uses a subset of markdown.  The
> exception being the syntax for links.

This is not true. Gemini has no concept of paragraphs, which
consequently allows for arbitrary functional line breaks anywhere in
text. These are simply line breaks in the source, which different from
any Markdown implementation I have used. In CommonMark, two spaces at
the end of a paragraph line indicates that the following line break is
a hard line break.

text/gemini also does not require a space between a heading indicator
and the heading content, for example, unlike CommonMark. The ambiguity
of the original Markdown description however means that some Markdown
parsers allow this anyway. That Markdown implementations currently
can't seem to stick to a canonical specification (even with the
existence of attempts like CommonMark) is further reason not to
consider it, IMO.

> Would it not be advantageous for content creators for Gemini to support both
> the standard Gemini syntax of => for links and also support the []()
> markdown syntax for links, limited to links on their own line?

No. It would be advantageous for authors that the formats remain as-is
so that not every author potentially have to update their every
document. It's also advantageous for implementors in that it doesn't
completely invalidate their parsers. It would perhaps be useful for
authors to have a tool that can translate between Markdown and
text/gemini, however.

> I am picturing a set of documents that could be delivered via Gemini as
> Gemini documents or delivered as markdown documents which then could be
> viewed as html or pdf.

What purpose does this fulfill? You can serve Markdown, HTML and PDF
with Gemini. I imagine that a server implementation could
automatically serve alternative versions of the text/gemini content
rendered in these formats, which would result in no changes to the
specification.

> This may just be crazy but I thought I would throw it out there.

Not crazy, but perhaps untimely. Gemini exists and is in use in its
current form. This suggests a breaking change that would invalidate
many existing documents, not just WRT links but for the other reasons
I've stated above. It would also invalidate a lot of existing client
implementations.

The Gemini FAQ states that "The current (informal) specification of
the protocol is largely frozen, modulo small changes to remove
ambiguity and address edge cases. Suggestions for new features will
not be considered, as the protocol is considered feature complete."
This is an important advantage. I still feel like whenever I check the
mailing list there are numerous suggestions for massively breaking
changes. This seems unproductive.

Best regards,
Philip