💾 Archived View for rawtext.club › ~sloum › geminilist › 006980.gmi captured on 2023-09-08 at 16:46:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Tue Aug 3 11:08:51 BST 2021
- - - - - - - - - - - - - - - - - - -
I accidentally sent this to just Robert, but it contains someobservations 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, whichconsequently allows for arbitrary functional line breaks anywhere intext. These are simply line breaks in the source, which different fromany Markdown implementation I have used. In CommonMark, two spaces atthe end of a paragraph line indicates that the following line break isa hard line break.
text/gemini also does not require a space between a heading indicatorand the heading content, for example, unlike CommonMark. The ambiguityof the original Markdown description however means that some Markdownparsers allow this anyway. That Markdown implementations currentlycan't seem to stick to a canonical specification (even with theexistence of attempts like CommonMark) is further reason not toconsider 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-isso that not every author potentially have to update their everydocument. It's also advantageous for implementors in that it doesn'tcompletely invalidate their parsers. It would perhaps be useful forauthors to have a tool that can translate between Markdown andtext/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 PDFwith Gemini. I imagine that a server implementation couldautomatically serve alternative versions of the text/gemini contentrendered in these formats, which would result in no changes to thespecification.
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 itscurrent form. This suggests a breaking change that would invalidatemany existing documents, not just WRT links but for the other reasonsI've stated above. It would also invalidate a lot of existing clientimplementations.
The Gemini FAQ states that "The current (informal) specification ofthe protocol is largely frozen, modulo small changes to removeambiguity and address edge cases. Suggestions for new features willnot be considered, as the protocol is considered feature complete."This is an important advantage. I still feel like whenever I check themailing list there are numerous suggestions for massively breakingchanges. This seems unproductive.
Best regards,Philip