Re: Raw string literals in Emacs lisp.

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     Well, I am not sure about the size of the wart in practice.  It has not
>     apparently caused much of a disturbance for XEmacs.  It certainly seems
>     less relevant in practice than our traditional wart
>
>     (info "(emacs) Left Margin Paren")
>
>     with regard to reliable detection of strings out of context.
>
> That problem is in a different feature (finding the start of a
> function), and we recommend a preventive measure to avoid it.

The preventive measure is not working in source buffers other than Elisp
and it requires manual intervention.  M-q seems to avoid _moving_ an
opening parent to the front of the line in strings: that is already a
big help in avoiding them to creep in when reformatting code.
auto-fill-mode however doesn't, so you don't get help against
accidentally introducing them.

> So it is not a real problem.  In Elisp, it is a solved problem.

More like a "problem with known manual workarounds".

> But even if it were a real problem, this argument is invalid in form.
> The existence of one problem we can't fix does not make it good
> to create another.

Sure.  I was just putting it in perspective: in practice the ambiguity
of r#"?\" without leading context is not going to cause anywhere near
the pain users already have to deal with.  I am not saying that this is
a non-problem.  But in contrast to the paren problem, it is a fringe
problem not likely to occur in practice.  So I consider it likely to be
less annoying in its effects to users than a raw string syntax diverging
from that of XEmacs which would basically imply that any portable code
has to forego raw strings completely.

Of course, if Emacs can come up with a significantly better proposal,
there is some likelihood that it will eventually _also_ be adopted by
XEmacs.

But as long as strings and raw strings share the same ending delimiter
and/or the ending delimiter of a raw string has a valid other syntactic
interpretation on its own, the ambiguity will be there.  ASCII does not
offer a wealth of delimiter candidates, and having to write something
like #r"fa\fa d\fd \fd safa"#r would likely be more annoying than the
problem it is supposed to cure.

I am not saying that #r"..." is what we should ultimately take, just
that I don't see the counterargument as weighing all that strongly.  I
actually would likely prefer something like #"..." as input but that's
even more likely to trip up backward parsing.

-- 
David Kastrup