Escaping in gemtext

[Ryan Westlund]

So if I understand Ali Fardan's suggestion, it is to introduce starting with '\'
as a signal for a new line type which could accomodate all of these issues. I
admit I like that it solves both the issues I mentioned with one change, even
the one I didn't think really needed a solution.

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.

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.

One comment on that same message:

> 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.

Ali's comment on the idea of using zero-width space
or ASCII backspace voices my own thoughts:

> Here you're making assumptions about how \b will be rendered, I'm not
> all against your approach, but I'm not also confident that all
> implementations will render this properly.

This is definitely my concern. Including invisible characters
that are outside of normal consideration seems like a bad idea.

In response to message from Sudipto Mallick:

> Use whitespace before the preformatted text and give warning
> to your reader to be careful when copying such text.

I don't like anything that requires "give warning to your reader", because
that's an admission that the markup is getting in the way. A markup format
shouldn't require telling your reader "I had to format this weirdly because
of the markup; you need to correct it".

> Maybe clients could do '''Maximum Common Frontal White Space
> Elimination''' in preformatted text blocks :P

But that could alter the meaning, for example if writing about indentation.

For the sake of use case: I write Python tutorials in Markdown, as well as
the specification for Sanemark, a variant of Markdown. Several similar issues
have come up for me before with Markdown (this specific one would've been a
major obstacle for the Sanemark spec if Markdown didn't implement what
I suggest, because leading space is significant).