Compare with Gemtext

[nichtich]

A more detailed comparision with Gemini's Gemtext could be helpful. I found this so far:

	subtext	gemtext
text blocks	any line not starting with a sigil	any line not starting with #, >, => or *
blank lines	ignored	are valid text blocks
links	& link	=> link optional-link-name
heading blocks	# heading	#, ## or ### followed by the heading
list blocks	- item	* item
quote blocks	> text	> text
space after sigil	required	optional
other sigils	reserved	become part of text blocks
preformatted	not supported	toggled with ```
line breaks	\n but \r\n is also also supported	\r\n but \n is also also supported

[nichtich]

Based on the comparison I'd recommend to

• make space after sigil optional
• think about why blank lines are ignored in the format when they could also be ignored on the client instead
• whether space characters in links should be discouraged

The main differences of subtext compared to gemtext would then be:

• slight syntax differences (- instead of * for lists, & instead of => for links)
• only one heading level
• no preformatted sections

The gemtext community argues against Mardown because of its complexity. Same could be argued to better use subtext instead if gemtext :stuck_out_tongue:

[gordonbrander]

Thanks! Subtext was originally sparked by seeing Runic. I loved the simplicity of its line-oriented markup, and was like "what if this, but with Markdown vibes?" After I shared out the first draft of Subtext, a friend cued me into Gemini. A lot of convergent evolution! Which suggests we're all pulling on a valuable thread here.

There are some differences in behavior, guided by solving for different design goals. E.g. Subconscious intends to lean heavily on transclusion. In Gemini clients "MUST NOT automatically make any network connections as part of displaying links" which is reasonable, but probably precludes transclusion for networked files. There may be other instances like this. I'm working on an MD->Subtext and Subtext->MD converters, so I can prototype Subtext with real-world note corpuses. Subtext will probably evolve in response to what we learn with these prototypes.

Quick thoughts on your bullets:

• Space after sigil: I think we may want to do this for future-proofness. Removing the space restriction allows each sigil to act as a "namespace" under which the syntax could potentially evolve. (see https://github.com/gordonbrander/subtext/issues/3#issuecomment-847216197)
• Blank lines: I had been turning this one over in my head for some days as well. After consideration, I think preserving blank lines may be the better approach. RFC here https://github.com/gordonbrander/subtext/blob/main/rfcs/2021-06-01-blank-lines.md.
• Links: likely to evolve in the direction sketched out here https://github.com/gordonbrander/subtext/blob/main/explorations/2021-05-28-multilinks.md

[gordonbrander]

https://github.com/gordonbrander/subtext/pull/13

[nichtich]

The use cases of subtext and gemtext differ but the similarities are remarkable and its good to have some compatibility (to be defined). Maybe also extend subtext blocks with levels, but only if needed. To experiment with subtext I though about a gemini server that serves subtext documents, so you can use any gemini client for browsing. Transclusion links could be kept as plain links or be served expanded.

[gordonbrander]

Appreciate this exploration, and the thoughtful comments. I've updated some of the spec after reflecting on your notes (https://github.com/gordonbrander/subtext/pull/13, https://github.com/gordonbrander/subtext/pull/14).

Despite similarities, direct syntax compatibility with Gemtext isn't a goal for Subtext. Subtext is something I'm working on as part of Subconscious, a notes app. It's important to me that Subtext be free to coevolve its features and design choices alongside Subconscious.

OTOH, for those who do want to create some kind of bridge, it should be fairly easy to create Subtext<->Gemtext converters, or parse Subtext and render Gemtext on the fly. Part of my goal for Subconscious is to have a format that is easy to parse into an Abstract Syntax Tree (or really, an Abstract Syntax List, since Subtext is flat). This lets anyone write scripts to transform it to and from other formats, or manipulate it using software. Building a parser for Subtext is simple (example in https://github.com/gordonbrander/subtext/tree/main/parsers), and I expect Gemtext is likely to be similarly simple.

Thank you again for the helpful feedback. Closing this for now, since I don't think there is any immediate action to take on the specification wrt this issue.