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: "Raw" string literals for elisp Date: Wed, 8 Sep 2021 21:28:08 +0000 Message-ID: References: <4209edd83cfee7c84b2d75ebfcd38784fa21b23c.camel@crossproduct.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24338"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Anna Glasgall Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 08 23:28:50 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 1mO57g-00067u-SG for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 23:28:48 +0200 Original-Received: from localhost ([::1]:38850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO57f-0001L1-FN for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 17:28:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO576-0000g7-Og for emacs-devel@gnu.org; Wed, 08 Sep 2021 17:28:12 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:62974 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mO574-0004G6-Ly for emacs-devel@gnu.org; Wed, 08 Sep 2021 17:28:12 -0400 Original-Received: (qmail 39068 invoked by uid 3782); 8 Sep 2021 21:28:08 -0000 Original-Received: from acm.muc.de (p4fe15ce6.dip0.t-ipconnect.de [79.225.92.230]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Sep 2021 23:28:08 +0200 Original-Received: (qmail 5346 invoked by uid 1000); 8 Sep 2021 21:28:08 -0000 Content-Disposition: inline In-Reply-To: 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, WEIRD_QUOTING=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:274396 Archived-At: Hello, Anna. On Wed, Sep 08, 2021 at 16:40:09 -0400, Anna Glasgall wrote: > On Tue, 2021-09-07 at 21:49 -0400, Anna Glasgall wrote: [ .... ] > Alan (Dr. Mackenzie? Forgive me, not sure what standards are here), Just "Alan" is fine. No, I don't have a PhD. :-) Young or old, novice or experienced, we just use first names around here. What is unwanted is unkind or hostile language, and curse words are not accepted at all, and never appear. But you don't seem like you want to write that way anyhow. ;-) > your point about strings ending in \ is very well taken and I'm frankly > not sure what the easiest path forward here is. Having "raw literals > cannot end in a \" is a weird and unpleasant restriction, although the > fact that it is one that Python places on r-strings (to my considerable > surprise; I've been using Python since the mid-00s and have never run > across this particular syntax oddity before) may mean that it is > perhaps not so bad. I think it would be bad in Emacs. Sooner or later somebody will be writing a regexp to match another regexp, and not being able to end in \ could be quite awkward. Maybe giving consideration to using the C# convention of representing a " in a raw string by "" would be advantageous. Even this isn't entirely simple, since a raw string with two "s in it would look something like #r"foo""""". From after the #r", to find the end of the raw string, you'd have to search for the first occurrence of an odd number of consecutive "s, which isn't entirely trivial. It might be a rare occurrence, but you've still got to handle it. Or, maybe something like the python convention: #r"......""", though this looks and feels somewhat wierd. > The C++ concept of allowing r-strings to specify their own delimiters > is perhaps maximally flexible, but is definitely going to be a heavier > lift to implement than any of the above. I'd love to hear people's > opinions on the merits of the various possible approaches here. When implementing the C++ raw strings, that flexibility caused me a lot of grief. For example, changing text in the middle of a C++ raw string, I had to check the new text didn't, by chance, form a closing delimiter matching the opening one. I would recommend not implementing anything like the C++ raw string identifiers. > You've all given me a great deal of food for thought, which I will > attempt to digest before spinning a new revision of this patch. > thanks, > Anna [ .... ] -- Alan Mackenzie (Nuremberg, Germany).