From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Brooks Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Tue, 02 Mar 2021 03:52:36 -0800 Message-ID: <87y2f5ixh7.fsf@db48x.net> 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39979"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: Matt Armstrong , Naoya Yamashita , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 02 12:53:17 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 1lH3aW-000AFu-QU for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 12:53:16 +0100 Original-Received: from localhost ([::1]:53600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lH3aV-0005F7-Sq for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 06:53:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH3Zz-0004qD-3K for emacs-devel@gnu.org; Tue, 02 Mar 2021 06:52:43 -0500 Original-Received: from smtp-out-4.mxes.net ([2605:d100:2f:10::315]:30241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lH3Zw-0004hf-Gw for emacs-devel@gnu.org; Tue, 02 Mar 2021 06:52:42 -0500 Original-Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4Dqb916dFRz3cBF; Tue, 2 Mar 2021 06:52:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1614685958; bh=4GPe+TXLWOvv1YN9UXo7rbZo8xWb9r8p0cVx8pYFboY=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=eRNUtUMvlZ3vfT/XJ3+NagpltmeP0Z/nr0pv9paAGFAFb6xAQCb1p6v+iFLR6xrJS 3kX2X7Wj93xf91esYccXsPMTHL22I92Rf65TpsSJ/gn4o6UVKQkgC9u7CVt5giwYC7 qlru7+EZ65+/+ByEJ1tE0am7aG9l3u8Mxm58ypwc= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGOfPtRkwAAABJQ TFRFpKfbdou67PD6JjJgAwUWXGSeIcyLHgAAAkZJREFUOI1VU8Fy6yAMxLi+Q13fCZ3cnQL3dqTc 7RD+/1feStDXVnXHDuvVSivZTMba2GPdw3gyCGcMAFxTyrTd9dwGoxHiZX9PmRFUHYAQlGGtXY+F Uk0SJOxgJiUEnH1qkitT9D+pQub7qGAmUbR6bu3CvI96Yv6QqkBBMrsyfZccr1/RDXGDTLf4P7ZY glVxe2V+/ACXWO1gvDO9/gDRpFFVmPluvLcmBjd5H6d8DEte+Pbk4rcY/Fa5tLKLOtCZsuQKYhpa LOkYDT7hESya7/WIET3lfQBqX0pwFtbI832Is0ayMUR9B+12xjgPCQ089cfwkCkX6L5TPmRelJTh zMS0Sz1PyjLAMCUWjcmgQLWQMds+e3aaauZDf9dU9A2/8kPVF2odCUoMKHkfjJR+mbgC+DRiycw5 3XSqGe6HmhN/AWjHypkAXOAFW5EiuA1ge2GiZuMb0s1fSEXcATeLUfbyEY2L8yPOmdSsdghQXx3K pz2eoeXuYvMCINVFDrCdNfVUp4eJ6cSEbjbgFjBEvonGGTrgv9cHjAc8aVgSAPoxaONbzfwhDIhR at7IIS7fAGiDSwIA9alhhTBzfA7YM2FY6eMwayrIGK8FDFmshmUA43WqhFtpvoqG9HHaJ7fqtgTz 8EWVkgZgtsylFliHDgk0MB7KAEC45C/rgnGvanNLXyzOeTzcT2nw/N44gfrtYXRQLoz9Q3TgmJRx 2Mx/Q51qzpm+l3m8z2SWBqC5+PZXAtNYlGFf/gKfHfjFkDT4x7od7R+w3Ls+ZdQBuQAAAABJRU5E rkJggg== In-Reply-To: (Alan Mackenzie's message of "Tue, 2 Mar 2021 11:14:56 +0000") X-Sent-To: Received-SPF: none client-ip=2605:d100:2f:10::315; envelope-from=db48x@db48x.net; helo=smtp-out-4.mxes.net 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_NONE=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:265822 Archived-At: Alan Mackenzie writes: > 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 =E2=80=9Cwins=E2=80=9D 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