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

[Daniel Brooks <db48x@db48x.net>]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Daniel.
>
> On Tue, Mar 02, 2021 at 01:56:43 -0800, Daniel Brooks wrote:
>> Matt Armstrong <matt@rfc20.org> writes:
>
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> > C++ has probably the most flexible "gold standard" raw string literals.
>
>> With respect, I think that Raku “wins” this
>> fight. https://docs.raku.org/language/quoting is really worth reading;
>> it's a work of art. You can think of the quote operator as a function
>> that takes 13 named boolean arguments plus a choice of opening and
>> closing delimiters.
>
> I haven't looked at raku, but I imagine that this "quoting" is something
> radically different from what we do in Emacs Lisp.

One of the things you can turn on or off is interpolation of values into
quoted strings, which is a lot like what elisp uses the backquote for.

>> I think the benefit will be worth it. If we offered a little more choice
>> of delimiters, then we could gain more benefit when the string must also
>> contain double quotes. This need have a large complexity cost.
>
> I think you meant to have a "not" in that last sentence, but also think
> it is correct as it stands.

Yes, I did mean that it shouldn't add much complexity.

> One of the things I didn't say explicitly in my last post was that with
> any form of raw string, lisp would need to put a syntax-table text
> property on each \ in such a string.  This needs to be done in an
> after-change function, possibly assisted by a before-change function.
> Any device to allow double quotes inside a raw string involves putting
> syntax-table properties on these, too.
>
> Having a choice of string delimiters makes things more complicated, too.
>
> And all the while, some functionality needs to guard against such a "
> becoming, or ceasing to be a raw string delimiter.
>
> I can think of two ways to do these things: One is to clear the entire
> raw string of all its syntax-table text properties at each change within
> (or near) it, then reapply them all.  This could be slow in a big raw
> string at normal typing speed.  The other way is to analyse carefully the
> text in the vicinity of a change and alter the text properties minimally,
> as needed.  C++ Mode takes this latter approach; it is complicated and
> difficult to get right.
>
> Currently, Emacs Lisp Mode doesn't need such change hooks.  Introducing
> them would be a significant increase in complexity, and I think this
> isn't worth it just to avoid having to quote backslashes in strings.

Hmm. I don't know much about the internals of how modes work, so I'll
just take all of that as a given.

The question then is do we as humans adapt ourselves to the limitations
of our editor, or do we adapt our editor to us? Extending lisp-mode to
handle raw string literals in elisp code has a one-time cost to a few of
us, but counting those backslashes our regexes has an ongoing cost to
all of us. We're not going to ditch regexes any time soon.

db48x