Re: "Raw" string literals for elisp

[Alan Mackenzie <acm@muc.de>]

Hello, Anna.

On Wed, Sep 08, 2021 at 16:40:09 -0400, Anna Glasgall wrote:
> On Tue, 2021-09-07 at 21:49 -0400, Anna Glasgall wrote:

[ .... ]

> Alan (Dr. Mackenzie? Forgive me, not sure what standards are here),

Just "Alan" is fine.  No, I don't have a PhD.  :-)  Young or old, novice
or experienced, we just use first names around here.  What is unwanted is
unkind or hostile language, and curse words are not accepted at all, and
never appear.  But you don't seem like you want to write that way anyhow.
;-)

> your point about strings ending in \ is very well taken and I'm frankly
> not sure what the easiest path forward here is. Having "raw literals
> cannot end in a \" is a weird and unpleasant restriction, although the
> fact that it is one that Python places on r-strings (to my considerable
> surprise; I've been using Python since the mid-00s and have never run
> across this particular syntax oddity before) may mean that it is
> perhaps not so bad.

I think it would be bad in Emacs.  Sooner or later somebody will be
writing a regexp to match another regexp, and not being able to end in \
could be quite awkward.

Maybe giving consideration to using the C# convention of representing a "
in a raw string by "" would be advantageous.  Even this isn't entirely
simple, since a raw string with two "s in it would look something like
#r"foo""""".  From after the #r", to find the end of the raw string,
you'd have to search for the first occurrence of an odd number of
consecutive "s, which isn't entirely trivial.  It might be a rare
occurrence, but you've still got to handle it.

Or, maybe something like the python convention: #r"......""", though this
looks and feels somewhat wierd.

> The C++ concept of allowing r-strings to specify their own delimiters
> is perhaps maximally flexible, but is definitely going to be a heavier
> lift to implement than any of the above. I'd love to hear people's
> opinions on the merits of the various possible approaches here.

When implementing the C++ raw strings, that flexibility caused me a lot
of grief.  For example, changing text in the middle of a C++ raw string,
I had to check the new text didn't, by chance, form a closing delimiter
matching the opening one.  I would recommend not implementing anything
like the C++ raw string identifiers.

> You've all given me a great deal of food for thought, which I will
> attempt to digest before spinning a new revision of this patch.

> thanks,

> Anna

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).