Escaping in gemtext

[Ali Fardan]

On Tue, 10 Nov 2020 00:19:53 -0500
Ryan Westlund <rlwestlund at gmail.com> wrote:
> 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.

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.

> And that is if escaping only considers syntax that would be
> interpreted anyway. If it implemented in a context-insensitive way,
> meaning a line starting with "\#" is still translated to "#" inside
> preformatted text, it could actually make the problem worse by
> increasing the number of preformatted lines that must be modified.

I suggested a special parser rule for preformatted text blocks that is
separate for the rule used for all other text, and this rule only
applies to '^\```', though I agree with your concerns.

> > also keep in mind that '\' does not only escape the character after
> > it, it disables line formatting, because in the example above, if
> > '=' is escaped, '>' is right after it and can be interpreted as a
> > quote.  
> 
> I don't see how this is correct? A quote line must start with >, not
> =>. If in "\=>", the \ escapes the = so that the resulting text is =>,
> I don't see how it could be interpreted as a quote.

I'm pointing out to those writing parsers to avoid the pitfall of just
skipping the character after that escape character and continuing as
normal from there, I do that myself so I thought it might be worth
noting, to clarify, if the parser ignores the character that is escaped
and continues as normal from there, then:

>	\=>

escaped only the '=' which means now that '>' is the first character in
the line and can be interpreted as a quote block, of course, this is
implementation specific, and I don't know how others have implemented
their parsers.