[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Interpret #r"..." as a raw string
From: |
Daniel Brooks |
Subject: |
Re: [PATCH] Interpret #r"..." as a raw string |
Date: |
Tue, 02 Mar 2021 03:52:36 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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
- Re: [PATCH] Interpret #r"..." as a raw string, (continued)
- Re: [PATCH] Interpret #r"..." as a raw string, Richard Stallman, 2021/03/01
- Re: [PATCH] Interpret #r"..." as a raw string, Alan Mackenzie, 2021/03/01
- Re: [PATCH] Interpret #r"..." as a raw string, Andreas Schwab, 2021/03/01
- Re: [PATCH] Interpret #r"..." as a raw string, Matt Armstrong, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Daniel Brooks, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Andreas Schwab, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Daniel Brooks, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Andreas Schwab, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Daniel Brooks, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Alan Mackenzie, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string,
Daniel Brooks <=
- Re: [PATCH] Interpret #r"..." as a raw string, Dmitry Gutov, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Alan Mackenzie, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Dmitry Gutov, 2021/03/02
- Re: [PATCH] Interpret #r"..." as a raw string, Alan Mackenzie, 2021/03/02
Re: [PATCH] Interpret #r"..." as a raw string, Aurélien Aptel, 2021/03/02