[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
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
- Re: Raw string literals in Emacs lisp., (continued)
- Re: Raw string literals in Emacs lisp., Alan Mackenzie, 2014/08/02
- Re: Raw string literals in Emacs lisp., Stephen J. Turnbull, 2014/08/03
- Re: Raw string literals in Emacs lisp., David Kastrup, 2014/08/03
- Re: Raw string literals in Emacs lisp., Stephen J. Turnbull, 2014/08/03
- Re: Raw string literals in Emacs lisp., David Kastrup, 2014/08/03
- Re: Raw string literals in Emacs lisp., Stephen J. Turnbull, 2014/08/03
- Re: Raw string literals in Emacs lisp., Richard Stallman, 2014/08/03
- Re: Raw string literals in Emacs lisp., David Kastrup, 2014/08/04
- Re: Raw string literals in Emacs lisp., Richard Stallman, 2014/08/04
- Re: Raw string literals in Emacs lisp.,
David Kastrup <=
- Re: Raw string literals in Emacs lisp., David Kastrup, 2014/08/03
- Re: Raw string literals in Emacs lisp., Stephen J. Turnbull, 2014/08/03
- Re: Raw string literals in Emacs lisp., Richard Stallman, 2014/08/03
Re: Raw string literals in Emacs lisp., Andreas Schwab, 2014/08/02