@; Hello world, Im a comment in TXR syntax - but I am also considered valid as a line of string in GemText @; Curiously, the uncommented TXR syntax is capable of building a new legal GemText document from this document @(bind uw_hello_world "Hello World!") @; The output function below provides a way of outputting GemText with minimal syntactic friction - to form distinct documents according to TXR coding @(output) # Demonstration of Gemini Specification Syntax This subsection includes examples of specification syntax * Im a bullet point => gemini://icebreaker.space project-uri-for-author ``` my comment for the block IM A BLOCK'S CONTENT ``` > This is a quote # Hello World Example This is a legal Gemini document. However, because of the ability for TXR to recognise TXR syntax it appears that .gmi files can be called within the Lisp dialect. Below is a 'Hello World' example. In it the content is different between the 'raw' and 'interpreted' GemTexts ``` demonstration @uw_hello_world ``` That is naturally something basic. However, TXR has both a pattern matching language and also a Lisp - which can be hugely powerful, given its FFI capabilities. => https://www.nongnu.org/txr/ TXR homepage Its worth providing an overview of the differences between the two GemText files: ``` sh command compiling 'raw' GemText file into 'interpreted' GemText file - influenced by specifics surrounding TXR and TXR content in the document. $ txr rq_the-trouble-with-glichen.gmi > uw_the-trouble-with-glichen.gmi ``` The diff provides an aperture regarding how this marriage of TXR and Gemini can be fruitful or a point of concern (such as Day-0 abuses): ``` $ diff uw_the-trouble-with-glichen.gmi rq_the-trouble-with-glichen.gmi ``` This such patches effectively isolate the existence of TXR syntax and its impact on GemText content These characteristics could be feasible for: * GemText documents being treated as application meshes * For people to inject TXR capabilities via patches into existing content - to generate outcomes not planned for by the original author(s) Naturally, this raises important questions regarding: * The limitations of TXR's extensibility with respect to GemText * Whether this unexpected pairing creates a wide range of security threats It may be worth noting that TXR scripts require an empty line at the end - failure to provide one generate a syntax error. Should TXR be considered a threat (rather than an opporunity to reconsider how Gemini exists functionally) then requiring non empty lines at the end of documents could help (though like banning '@' signs in sting lines - it would not help if (say) state actors mitigated these with tronsposed TXR syntaxes). @(end)