💾 Archived View for gemi.dev › gemini-mailing-list › 000976.gmi captured on 2023-11-04 at 13:14:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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. 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? I also think it would be great if markdown also supported both syntaxes. 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. This may just be crazy but I thought I would throw it out there.
Rev. Fr. Robert Bower <frrobert at frrobert.com> writes: > 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. > > 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? > > I also think it would be great if markdown also supported both syntaxes. > > 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. > > This may just be crazy but I thought I would throw it out there. I think this was discussed before, but one of the core point of text/gemini is the idea of line types: each line has a type and there aren't inline objects. It's weird at first, but after a while it becomes better than inline links IMHO. Yes, one needs to adjust the style of the writing because cluttering the paragraphs of [0], ?, etc isn't that great. This article makes some good points in that regard: gemini://idiomdrottning.org/re-why-u-no-gemini Said that, this doesn't stop you from serving markdown, pdfs or anything else over gemini. Just call your file .md instead of .gmi and use inline links etc... HTH
July 28, 2021 4:42 PM, "Omar Polo" <op at omarpolo.com> wrote: > I think this was discussed before, but one of the core point of > text/gemini is the idea of line types: each line has a type and there > aren't inline objects. They weren't asking for inline links (emphasis mine): Rev. Fr. Robert Bower <frrobert at frrobert.com> writes: > -snip- > 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?* > -snip- I, for one, think Gemini links are fine just the way they are, but it's food for thought. Just my two cents, Robert "khuxkm" Miles
The justification I have seen for the status quo is that, currently, a client only needs to examine the first 3(?) characters of a line to determine its line type. That's quite elegant and makes it exceptionally easy to parse gemtext. This suggestion would break that feature and I'm not sure there is any real benefit to doing so. What is the motivation here - is it to make gemtext a subset of markdown? Alan On 29/07/2021 23:57, Robert "khuxkm" Miles wrote: > July 28, 2021 4:42 PM, "Omar Polo" <op at omarpolo.com> wrote: > >> I think this was discussed before, but one of the core point of >> text/gemini is the idea of line types: each line has a type and there >> aren't inline objects. > They weren't asking for inline links (emphasis mine): > > Rev. Fr. Robert Bower <frrobert at frrobert.com> writes: > >> -snip- >> 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?* >> -snip- > I, for one, think Gemini links are fine just the way they are, but it's food for thought. > > Just my two cents, > Robert "khuxkm" Miles
On 2021-07-30 01:48, Alan wrote: > What is the motivation here - is it to make gemtext a subset of markdown? It already is. > Any sequence of characters is a valid CommonMark document. > > A character is a Unicode code point. Although some code points (for > example, combining accents) do not correspond to characters in an > intuitive sense, all code points count as characters for purposes of > this spec. > > <...> https://spec.commonmark.org/0.30/
Robert "khuxkm" Miles <khuxkm at tilde.team> writes: > July 28, 2021 4:42 PM, "Omar Polo" <op at omarpolo.com> wrote: > >> I think this was discussed before, but one of the core point of >> text/gemini is the idea of line types: each line has a type and there >> aren't inline objects. > > They weren't asking for inline links (emphasis mine): I completely missed that, sorry > Rev. Fr. Robert Bower <frrobert at frrobert.com> writes: > >> -snip- >> 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?* >> -snip- > > I, for one, think Gemini links are fine just the way they are, but it's food for thought. > > Just my two cents, > Robert "khuxkm" Miles
Omar Polo <op at omarpolo.com> writes: > Said that, this doesn't stop you from serving markdown, pdfs or anything > else over gemini. Just call your file .md instead of .gmi and use > inline links etc... Alternatively, generate .gmi from Markdown. In my local experimentation, I'm using 7off (gemini://idiomdrottning.org/7off). -- Chris
My thought in having a common link syntax is authors could create content that could be delivered via gemini or html with no need to do conversion. In fact both servers could use a common set of documents. On July 29, 2021 8:48:50 PM EDT, Alan <gemini at bunburya.eu> wrote: >The justification I have seen for the status quo is that, currently, a >client only needs to examine the first 3(?) characters of a line to >determine its line type. That's quite elegant and makes it >exceptionally easy to parse gemtext. This suggestion would break that >feature and I'm not sure there is any real benefit to doing so. > >What is the motivation here - is it to make gemtext a subset of >markdown? > >Alan > >On 29/07/2021 23:57, Robert "khuxkm" Miles wrote: >> July 28, 2021 4:42 PM, "Omar Polo" <op at omarpolo.com> wrote: >> >>> I think this was discussed before, but one of the core point of >>> text/gemini is the idea of line types: each line has a type and >there >>> aren't inline objects. >> They weren't asking for inline links (emphasis mine): >> >> Rev. Fr. Robert Bower <frrobert at frrobert.com> writes: >> >>> -snip- >>> 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?* >>> -snip- >> I, for one, think Gemini links are fine just the way they are, but >it's food for thought. >> >> Just my two cents, >> Robert "khuxkm" Miles -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Fri, Jul 30, 2021 at 12:51:42AM -0700, Chris Brannon wrote: > Omar Polo <op at omarpolo.com> writes: > > > Said that, this doesn't stop you from serving markdown, pdfs or anything > > else over gemini. Just call your file .md instead of .gmi and use > > inline links etc... > > Alternatively, generate .gmi from Markdown. In my local > experimentation, I'm using 7off (gemini://idiomdrottning.org/7off). I wrote a filter for doing it the other way. https://gitlab.com/tidux/gmi2mkd -- tidux at sdf.org SDF Public Access UNIX System - http://sdf.org
On Fri, 30 Jul 2021 15:37:26 -0400, Rev. Fr. Robert Bower wrote: > My thought in having a common link syntax is authors could create > content that could be delivered via gemini or html with no need to do > conversion. In fact both servers could use a common set of documents. Using the same simple source for Gemini (without conversion) and Markdown (to be converted to HTML) alike, lists of URLs can be authored by adding markdown line breaks, i. e. adding two spaces (or a backslash) at the end, e. g.: => url1 => url2 linktext Not too nice in HTML as linktext is not hyperlinked, though; so this is probably only good enough for bare links without any linktext.
On 7/30/21, Anna ?CyberTailor? <cyber at sysrq.in> wrote: > On 2021-07-30 01:48, Alan wrote: >> What is the motivation here - is it to make gemtext a subset of markdown? > > It already is. > >> Any sequence of characters is a valid CommonMark document. The question is of course whether the markup of gemtext should be a subset of the markup of markdown. That is, whether sequences of text that indicate a special meaning in CommonMark should also have that same meaning in gemtext. In that sense, it is not. Best regards, Philip
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
---
Previous Thread: Gemini specification repo at GitLab
Next Thread: 1. Re: [Tech][Idea]Link syntax (Rev. Fr. Robert Bower