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: Mon, 1 Mar 2021 12:06:48 +0000 Message-ID: References: <20210227.031857.1351840144740816188.conao3@gmail.com> 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="40473"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Naoya Yamashita Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 01 13:07:52 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 1lGhL6-000AQm-2C for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Mar 2021 13:07:52 +0100 Original-Received: from localhost ([::1]:59542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGhL5-0001pY-24 for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Mar 2021 07:07:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGhKC-0001OD-LG for emacs-devel@gnu.org; Mon, 01 Mar 2021 07:06:56 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:56692 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lGhK8-0006lF-QM for emacs-devel@gnu.org; Mon, 01 Mar 2021 07:06:56 -0500 Original-Received: (qmail 81050 invoked by uid 3782); 1 Mar 2021 12:06:49 -0000 Original-Received: from acm.muc.de (p4fe15d36.dip0.t-ipconnect.de [79.225.93.54]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 01 Mar 2021 13:06:48 +0100 Original-Received: (qmail 5833 invoked by uid 1000); 1 Mar 2021 12:06:48 -0000 Content-Disposition: inline In-Reply-To: <20210227.031857.1351840144740816188.conao3@gmail.com> 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:265770 Archived-At: Hello, Naoya. On Sat, Feb 27, 2021 at 03:18:57 +0900, Naoya Yamashita wrote: > Hi, all. > I write a patch to allow Emacs reader interpret raw string. > As you know, we already has some special marker using `#` to make > Emacs reader work in a special way. For example, we have `#[` to > indicate byte-compiled object and `#s(` to indicate hash-table. > I introduce raw string using this architecture, if users put `#r` > before string, Emacs reader interpret it as a raw string. > Many programming language has a Raw string feature[^1], so I want to > use raw string in Emacs-lisp. 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 \\\\. > To see more concrete example, please see the attached patch testcases. > Regards, > Naoya [ .... ] -- Alan Mackenzie (Nuremberg, Germany).