Escaping in gemtext
Ryan Westlund
rlwestlund at gmail.com
Tue Nov 10 15:00:17 GMT 2020
Sean Conner wrote:
>It was thus said that the Great Ryan Westlund once stated:
>> The main reason I don't prefer it to my own suggestion is that it would
>> still mean that preformatted lines might need to be altered in some way
>> (if the preformatted lines contain "\```" or something), instead of
>> allowing to paste them in unmodified and only have to modify the
>> prefomatting toggle lines.
> Sorry, no way around that. I mean, one *could* use HTML entities:
The point of that paragraph was that my proposal makes it so that you
only have to modify the preformatting toggle lines to paste in
arbitrary content, not the content itself. It does achieve that.
(CDATA does not because the string "]]>" ends it and there is no rule
about matching the number about brackets used to open it, so a CDATA
section cannot include "]]>".)
For what it's worth, the reason I don't think HTML needs this as much
as gemtext is because HTML already has a general escaping mechanism,
and is not necessarily meant to be written by hand anyway.
Ali Fardan wrote:
> Indeed it is ugly, one other workaround to this is having
>
>> ```
>> ```
>
> interpreted as literal '```' to avoid altering preformatted text, and
> to be clear, this does not apply to the case of having multiple
> preformatted text blocks next to each other, this only applies to a
> single preformatted text block that contains nothing..
Interesting. Clarification: is this like PostgreSQL string escapes,
where two consecutive toggle lines inside a block come out as a
literal "```"? Or does it only apply to empty blocks (and not the same
pattern within a block with other content), so that embedding a
literal "```" requires four in a row (one to end the current block,
then two for the literal sequence, then the fourth to open another
preformatting block - assuming two adjacent blocks will be merged)?
More information about the Gemini
mailing list