unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Daniel Brooks <db48x@db48x.net>
Cc: Matt Armstrong <matt@rfc20.org>,
	Naoya Yamashita <conao3@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: [PATCH] Interpret #r"..." as a raw string
Date: Tue, 2 Mar 2021 11:14:56 +0000	[thread overview]
Message-ID: <YD4eMLvBESJVjfJb@ACM> (raw)
In-Reply-To: <87blc1khes.fsf@db48x.net>

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.

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

> Certainly true. As the ordinary Lisp string syntax already allows
> multi-line strings, and interpolation is handled by the format function,
> the primary benefit is to turn off escaping. We could also offer a
> choice of opening and closing delimiters, though the proposed code
> didn't implement that.

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

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.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).



  parent reply	other threads:[~2021-03-02 11:14 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 18:18 [PATCH] Interpret #r"..." as a raw string Naoya Yamashita
2021-02-26 18:27 ` [External] : " Drew Adams
2021-02-26 18:53   ` Naoya Yamashita
2021-02-26 19:03     ` Drew Adams
2021-02-26 19:48     ` Stefan Monnier
2021-02-26 20:23       ` Naoya Yamashita
2021-02-26 20:34         ` Andreas Schwab
2021-02-26 20:39           ` Naoya Yamashita
2021-02-26 20:45             ` Andreas Schwab
2021-02-26 20:50               ` Naoya Yamashita
2021-02-26 20:54                 ` Andreas Schwab
2021-02-26 20:03     ` Eli Zaretskii
2021-02-26 20:34       ` Naoya Yamashita
2021-02-26 19:09 ` Andreas Schwab
2021-02-26 20:00 ` Eli Zaretskii
2021-02-27  0:39   ` Daniel Brooks
2021-02-27 16:14     ` Richard Stallman
2021-02-27 16:18       ` Stefan Monnier
2021-03-01  5:19         ` Richard Stallman
2021-03-02  5:45           ` Matt Armstrong
2021-03-03  5:53             ` Richard Stallman
2021-03-03  6:14               ` Daniel Brooks
2021-03-03  7:00               ` Eli Zaretskii
2021-03-04  2:47                 ` Matt Armstrong
2021-03-04 13:49                   ` Eli Zaretskii
2021-03-04 16:55                     ` Matt Armstrong
2021-03-05  5:44                       ` Richard Stallman
2021-03-05  5:39                   ` Richard Stallman
2021-03-05  8:01                     ` Eli Zaretskii
2021-03-06  5:13                       ` Richard Stallman
2021-03-06  6:04                         ` Matt Armstrong
2021-03-07  6:13                           ` Richard Stallman
2021-03-07 17:20                             ` [External] : " Drew Adams
2021-03-06  8:27                         ` Eli Zaretskii
2021-03-06  9:51                           ` Daniel Brooks
2021-03-06 10:24                             ` Eli Zaretskii
2021-03-07  6:08                           ` Richard Stallman
2021-02-27 20:41       ` Daniel Brooks
2021-02-28  6:22 ` Zhu Zihao
2021-03-01  5:26   ` Richard Stallman
2021-03-01 12:06 ` Alan Mackenzie
2021-03-01 12:13   ` Andreas Schwab
2021-03-02  5:59   ` Matt Armstrong
2021-03-02  9:56     ` Daniel Brooks
2021-03-02 10:13       ` Andreas Schwab
2021-03-02 10:55         ` Daniel Brooks
2021-03-02 11:18           ` Andreas Schwab
2021-03-02 11:26             ` Daniel Brooks
2021-03-02 11:14       ` Alan Mackenzie [this message]
2021-03-02 11:52         ` Daniel Brooks
2021-03-02 12:01     ` Dmitry Gutov
2021-03-02 14:14       ` Alan Mackenzie
2021-03-02 14:32         ` Dmitry Gutov
2021-03-02 15:06           ` Alan Mackenzie
2021-03-02 11:41 ` Aurélien Aptel
2021-03-02 13:49   ` Stefan Monnier
2021-03-02 14:46     ` Aurélien Aptel
2021-03-02 15:11       ` Stefan Monnier
2021-03-02 16:07         ` Aurélien Aptel
2021-03-03  7:31           ` Alfred M. Szmidt
2021-03-03 16:02           ` Stefan Monnier
2021-03-02 20:36     ` Daniel Brooks
2021-03-03  0:27       ` Stefan Monnier
2021-03-03  0:42         ` Daniel Brooks
2021-03-03  8:16       ` Andreas Schwab
2021-03-03  9:25         ` Daniel Brooks
2021-03-03  9:29           ` Andreas Schwab
2021-03-03 10:02             ` Daniel Brooks
2021-03-03 10:11               ` Daniel Brooks
2021-03-03 10:14                 ` Andreas Schwab
2021-03-03 11:48                   ` Daniel Brooks
2021-03-03 10:12       ` Michael Albinus
2021-03-03 10:42         ` Daniel Brooks
2021-03-03 10:49           ` Michael Albinus
2021-03-03 16:12           ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YD4eMLvBESJVjfJb@ACM \
    --to=acm@muc.de \
    --cc=conao3@gmail.com \
    --cc=db48x@db48x.net \
    --cc=emacs-devel@gnu.org \
    --cc=matt@rfc20.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).