Re: [PATCH] Interpret #r"..." as a raw string

[Matt Armstrong <matt@rfc20.org>]

Alan Mackenzie <acm@muc.de> writes:

> I'm against introducing raw strings into Emacs Lisp.  There just doesn't
> seem to be a need, and there are several disadvantages.
>
> Firstly, it would make the language more complicated, and thus more
> difficult to learn - "What does this #r mean?".
>
> Raw strings themselves are complicated beasts, more so than your post
> suggests.  (I've implemented them for C++ Mode.)
>
> We'd have to decide which characters are valid inside raw strings -
> for example, is a linefeed valid?  If so, we'd have to decide how to
> fontify a newly opened raw string, which at first would extend to the
> end of the buffer.  We'd have to decide how to do fontification when a
> " gets inserted into the middle of an already valid raw string.
>
> The " character can't be inserted into a raw string - that limits
> their usefulness quite a lot.  Sooner or later, somebody will suggest
> some "enhancement" to allow this, increasing the complication even
> more.  Indeed, this has already happened, with somebody suggesting
> using variable length string delimiters, or suchlike.  Such strings
> could not be fontified simply by the syntax routines, as they are now.
>
> Then there is the handling of raw strings by the regexp engine, as
> Andreas has already pointed out.  There will be confusion in whether
> or not a doubled backslash in a regexp has to be written as \\ or \
> inside a raw string.  Currently, we have the invariable \\\\.

Yes, it'd be nice to see a clear description of what problems this
proposal is designed to solve.  The name alone is not clear because not
every langauge has the same "raw string" semantics.  Are these like C++
raw string literals or something closer to Python's single quote?

C++ has probably the most flexible "gold standard" raw string literals.
As Alan I think rightly points out, this makes the language and all
tools that process the language more complex.  This is a high cost, so
the feature should deliver some real value.

For those that don't know, C++'s raw string literals can be as imple as
this for the string "raw-content":

   R"(raw-content)"

But if the content itself contains the character sequence )" then the
programmer can specify any delimiter they want:

   R"DELIMITER(raw-content)"more-raw-content)DELIMITER"

But as you can see above, it isn't always clearer to write a raw string
literal.