From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: regular expressions that match nothing Date: Fri, 17 May 2019 09:43:01 +0000 Message-ID: <20190517094301.GA5011@ACM> References: <7a6b23f52418b093a4cf7a6db4306cf425533249.camel@acm.org> <20190515194129.GA4103@ACM> <39a146e4709b532db817abc47f17799b@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="22606"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= , Stefan Monnier , emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 17 11:44:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRZQ6-0005i0-5o for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 11:44:54 +0200 Original-Received: from localhost ([127.0.0.1]:45322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRZQ4-0006hh-Rx for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 05:44:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRZOT-0006Hi-JK for emacs-devel@gnu.org; Fri, 17 May 2019 05:43:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRZOR-00024G-RC for emacs-devel@gnu.org; Fri, 17 May 2019 05:43:13 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16972 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hRZOR-0001k5-Ga for emacs-devel@gnu.org; Fri, 17 May 2019 05:43:11 -0400 Original-Received: (qmail 6370 invoked by uid 3782); 17 May 2019 09:43:03 -0000 Original-Received: from acm.muc.de (p4FE15D06.dip0.t-ipconnect.de [79.225.93.6]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 17 May 2019 11:43:01 +0200 Original-Received: (qmail 5076 invoked by uid 1000); 17 May 2019 09:43:01 -0000 Content-Disposition: inline In-Reply-To: <39a146e4709b532db817abc47f17799b@webmail.orcon.net.nz> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236639 Archived-At: Hello, Phil. On Fri, May 17, 2019 at 11:18:49 +1200, Phil Sainty wrote: > > 15 maj 2019 kl. 21.41 skrev Alan Mackenzie : > >> I think regexp-unmatchable is too much of a mouthful. > I like it, myself. I think the meaning is 100% clear and unambiguous > for the reader (which I can't say about the alternative suggestions > that I've seen). I find it too difficult to read. My brain simply doesn't recognise it instantly, the way it would re-nomatch. At the moment, given there is no similar symbol name in Emacs, this is less urgent, but if more similar long symbols were introduced this would be a pain - a minor pain yes, but a pain nevertheless. > Are we expecting this to be used so much that we're prioritising > brevity over clarity? Brevity is clarity - up to a point. We write `defun', not `define-function'. Who would argue that the latter of these is clearer? Why has nobody commented on my suggestion of using re- rather than regexp- as the prefix? We already have re-search-forward. > (That's a genuine question -- I have a similar definition in my own > config, and I have exactly one use for it.) There are quite a few uses of "a\\`" in CC Mode. If they were to be replaced by regexp-unmatchable, I might have to re-flow the code, to avoid it going too far over 80 columns. > On 2019-05-16 22:54, Mattias Engdegård wrote: > > 4. The point of this name isn't to be shorter than the regexp string > > it represents, but to be more readable and avoid mistakes and > > substandard reinventions. > Quite. > > 2. (rx (or)) is even shorter than re-nomatch, and is very memorable. > > (rx (|)) is shorter still. This is undesirable in source files which don't otherwise use rx. It's also cryptic, forcing some readers to do research. > I don't think those are much better than people using "a\\`". > *Surely* `rx` can simply acquire a symbol for this? > (rx unmatchable) or similar? > -Phil -- Alan Mackenzie (Nuremberg, Germany).