From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Tue, 2 Mar 2021 11:14:56 +0000 Message-ID: References: <20210227.031857.1351840144740816188.conao3@gmail.com> <87blc1khes.fsf@db48x.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Matt Armstrong , Naoya Yamashita , emacs-devel@gnu.org To: Daniel Brooks Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 02 12:19:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lH34D-0004SA-9N for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 12:19:53 +0100 Original-Received: from localhost ([::1]:44366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH34C-0004n1-AL for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 06:19:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH2zY-0001pP-7b for emacs-devel@gnu.org; Tue, 02 Mar 2021 06:15:04 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:36172 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lH2zV-0007jH-QU for emacs-devel@gnu.org; Tue, 02 Mar 2021 06:15:03 -0500 Original-Received: (qmail 21040 invoked by uid 3782); 2 Mar 2021 11:14:57 -0000 Original-Received: from acm.muc.de (p4fe15a8d.dip0.t-ipconnect.de [79.225.90.141]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Mar 2021 12:14:57 +0100 Original-Received: (qmail 8923 invoked by uid 1000); 2 Mar 2021 11:14:56 -0000 Content-Disposition: inline In-Reply-To: <87blc1khes.fsf@db48x.net> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265818 Archived-At: Hello, Daniel. On Tue, Mar 02, 2021 at 01:56:43 -0800, Daniel Brooks wrote: > Matt Armstrong writes: > > Alan Mackenzie 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).