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

[Alan Mackenzie <acm@muc.de>]

Hello, Naoya.

On Sat, Feb 27, 2021 at 03:18:57 +0900, Naoya Yamashita wrote:
> Hi, all.

> I write a patch to allow Emacs reader interpret raw string.

> As you know, we already has some special marker using `#` to make
> Emacs reader work in a special way.  For example, we have `#[` to
> indicate byte-compiled object and `#s(` to indicate hash-table.

> I introduce raw string using this architecture, if users put `#r`
> before string, Emacs reader interpret it as a raw string.

> Many programming language has a Raw string feature[^1], so I want to
> use raw string in Emacs-lisp.

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

> To see more concrete example, please see the attached patch testcases.

> Regards,
> Naoya

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).