emacs-devel
[Top][All Lists]
Advanced

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

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


From: Alan Mackenzie
Subject: Re: [PATCH] Interpret #r"..." as a raw string
Date: Tue, 2 Mar 2021 14:14:32 +0000

Hello, Dmitry

On Tue, Mar 02, 2021 at 14:01:10 +0200, Dmitry Gutov wrote:
> On 02.03.2021 07:59, Matt Armstrong wrote:
> > 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"

> Sounds very similar to Ruby's heredocs or "Percent Strings" (and both of 
> those have their own extra complexity because of allowed nesting).

> Both are supported by ruby-mode with syntax-propertize-function without 
> too much trouble.

I've just tried this out, looking up some ruby syntax on Wikipedia.
Adapting its example, start out with this in ruby-mode:

#########################################################################
a = <<-BLOCK

This is a double-quoted string
BLCK
BLOCK
b
#########################################################################

Now everything down to and including the second BLOCK has string face.
This seems correct.  Delete the O from the first BLOCK, so that the
string is now terminated by BLCK.  The second BLOCK still has string
face, although it is no longer in the string.  Is this a bug?

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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