[Tech][Idea]Link syntax

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@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@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@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@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@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@tilde.team> writes:

> July 28, 2021 4:42 PM, "Omar Polo" <op@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@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@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@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@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@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@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@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@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@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