From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: "Raw" string literals for elisp Date: Wed, 08 Sep 2021 16:18:23 -0400 Message-ID: References: <4209edd83cfee7c84b2d75ebfcd38784fa21b23c.camel@crossproduct.net> <20210908160531.GA18656@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14371"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 08 22:19:45 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 1mO42r-0003YP-KK for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 22:19:45 +0200 Original-Received: from localhost ([::1]:41922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO42q-0004LN-DQ for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 16:19:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO41f-0002ZO-Qm for emacs-devel@gnu.org; Wed, 08 Sep 2021 16:18:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12975) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO41c-0007Sg-Fw for emacs-devel@gnu.org; Wed, 08 Sep 2021 16:18:30 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8A8D4100142; Wed, 8 Sep 2021 16:18:30 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E3A2710012C; Wed, 8 Sep 2021 16:18:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1631132308; bh=FiUj6ZIJwBasmUa4l0nl8SYDkha7AnVXd6FOUpbpoAg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NBnAurO+XnAaGs4S1T2GeUCQkpItsRhNus90JTNLlwiCsMbj4in670n6RS2GMGy+k NOVe/bOqUgmvaINGD/BfBgC0ATH1CtjcSWLHFkRutHxWrnWpuwk2ZjDoR68Rg83jWY RnXCCi/TmvSRs56+r53XZEYtAmmraOQ1oAbVysAamlPmIJA+joGq5trq5JWm2cq+++ tZMPCB9jdcGkGw3hkvnRdJZiMYUJO8CDn/NWMbimo022x++htLmTBjB2drU9Fhul0J bahACU8PUCIs+bFvX7U9eiL1g7fe9eVw87NaESIl8DL4LYic6tZhLave8LnTKkPBDZ 3KyiTNvMGkJ+w== Original-Received: from pastel (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B8D9C120296; Wed, 8 Sep 2021 16:18:24 -0400 (EDT) In-Reply-To: <20210908160531.GA18656@tuxteam.de> (tomas@tuxteam.de's message of "Wed, 8 Sep 2021 18:05:32 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:274388 Archived-At: > I just think these are two separate dimensions which happen to align > in the "regexp and backslash" case. BTW, they can align in somewhat funny ways sometimes. E.g. the raw-string version of the regexp "[ \t\n]" turns into something like #r"[ ]" which is not ideal in terms of clarity. Similarly a regexp that matches the NUL character will be problematic when written as a raw string because it will need to embed the NUL character in the source code, which in turn will cause tools like `grep` to treat the file as binary. For the first problem above we can/should extend our regexp syntax to include \t and \n as regexps that match TAB and LF respectively (that would also be handy when writing regexps in the minibuffer). But \0 is already used for other things so there's no such "obvious" workaround for the second case :-( Stefan