From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: :alnum: broken? Date: Fri, 28 Feb 2020 00:48:32 -0800 Organization: UCLA Computer Science Department Message-ID: <1c654ac9-10a2-4e5d-f77c-3b78bb580ffc@cs.ucla.edu> References: <86wo8flqct.fsf@stephe-leake.org> <86sgj3ljf0.fsf@stephe-leake.org> <5fecc0e1-1ee2-5a89-9297-b0b9aa4a8e9c@cs.ucla.edu> <03A37C4B-9FE8-4A25-9851-79BC8265455E@acm.org> <142e845d-eba3-5975-fa63-4c1b14ed4600@cs.ucla.edu> <3A14F30E-60EF-4C99-AC1A-9A1B2539169B@acm.org> <837e07gmka.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114701"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 28 09:49:23 2020 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 1j7bKk-000TkC-Qz for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Feb 2020 09:49:22 +0100 Original-Received: from localhost ([::1]:43696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7bKj-0005A5-TG for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Feb 2020 03:49:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45811) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7bK2-0004aW-Mo for emacs-devel@gnu.org; Fri, 28 Feb 2020 03:48:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7bK1-0000S5-Cu for emacs-devel@gnu.org; Fri, 28 Feb 2020 03:48:38 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:43826) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j7bJz-0000Qk-NX; Fri, 28 Feb 2020 03:48:35 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 929C7160087; Fri, 28 Feb 2020 00:48:33 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vZIR7TCdt7Sc; Fri, 28 Feb 2020 00:48:32 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D973416008E; Fri, 28 Feb 2020 00:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p7mSNCdD8R6E; Fri, 28 Feb 2020 00:48:32 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A9C35160087; Fri, 28 Feb 2020 00:48:32 -0800 (PST) In-Reply-To: <837e07gmka.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:245098 Archived-At: On 2/28/20 12:09 AM, Eli Zaretskii wrote: > I don't believe it is right for us to reject questionable but > valid code. That begs the question. The code is valid only if we continue to insist that it be valid, despite the clear drawbacks of doing so. Instead, we can easily change the definition of Emacs regular expressions so that the code is invalid. Since such code is invariably a mistake, it's a win to make such a change. That's what GNU grep has done for many years, and it works. > I can even agree to reject this at > run time under a non-default value of some special variable That would be better than nothing, but it's not very good since most people won't know about the variable and thus will continue to suffer from these errors. Better would be to make the default reject these buggy regexps, which is what GNU grep does (it accepts the buggy regexps only if POSIXLY_CORRECT is set).