From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Interpret #r"..." as a raw string Date: Mon, 01 Mar 2021 21:59:33 -0800 Message-ID: References: <20210227.031857.1351840144740816188.conao3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5997"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie , Naoya Yamashita Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 02 07:07:38 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 1lGyC2-0001RA-CS for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 07:07:38 +0100 Original-Received: from localhost ([::1]:53504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGyC1-00013P-CG for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Mar 2021 01:07:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGy4N-0008GR-Qw for emacs-devel@gnu.org; Tue, 02 Mar 2021 00:59:45 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:58333) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGy4L-0004QZ-47 for emacs-devel@gnu.org; Tue, 02 Mar 2021 00:59:42 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id B6823FF803; Tue, 2 Mar 2021 05:59:36 +0000 (UTC) In-Reply-To: Received-SPF: pass client-ip=217.70.183.199; envelope-from=matt@rfc20.org; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:265807 Archived-At: Alan Mackenzie writes: > I'm against introducing raw strings into Emacs Lisp. There just doesn't > seem to be a need, and there are several disadvantages. > > Firstly, it would make the language more complicated, and thus more > difficult to learn - "What does this #r mean?". > > Raw strings themselves are complicated beasts, more so than your post > suggests. (I've implemented them for C++ Mode.) > > We'd have to decide which characters are valid inside raw strings - > for example, is a linefeed valid? If so, we'd have to decide how to > fontify a newly opened raw string, which at first would extend to the > end of the buffer. We'd have to decide how to do fontification when a > " gets inserted into the middle of an already valid raw string. > > The " character can't be inserted into a raw string - that limits > their usefulness quite a lot. Sooner or later, somebody will suggest > some "enhancement" to allow this, increasing the complication even > more. Indeed, this has already happened, with somebody suggesting > using variable length string delimiters, or suchlike. Such strings > could not be fontified simply by the syntax routines, as they are now. > > Then there is the handling of raw strings by the regexp engine, as > Andreas has already pointed out. There will be confusion in whether > or not a doubled backslash in a regexp has to be written as \\ or \ > inside a raw string. Currently, we have the invariable \\\\. Yes, it'd be nice to see a clear description of what problems this proposal is designed to solve. The name alone is not clear because not every langauge has the same "raw string" semantics. Are these like C++ raw string literals or something closer to Python's single quote? C++ has probably the most flexible "gold standard" raw string literals. 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. For those that don't know, C++'s raw string literals can be as imple as this for the string "raw-content": R"(raw-content)" But if the content itself contains the character sequence )" then the programmer can specify any delimiter they want: R"DELIMITER(raw-content)"more-raw-content)DELIMITER" But as you can see above, it isn't always clearer to write a raw string literal.