[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Raw string literals in Emacs lisp.

From: David Kastrup
Subject: Re: Raw string literals in Emacs lisp.
Date: Tue, 05 Aug 2014 08:15:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Richard Stallman <address@hidden> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]