From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: :alnum: broken? Date: Fri, 28 Feb 2020 00:17:22 +0100 Message-ID: <87o8tj4o3h.fsf@telefonica.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101399"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.60 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:CpCs/e0zG42XpmxjNpzd/3TljqY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 28 00:18:00 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 1j7SPn-000QCz-FS for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Feb 2020 00:17:59 +0100 Original-Received: from localhost ([::1]:39520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7SPm-0002YJ-HD for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Feb 2020 18:17:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58928) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7SPK-00026u-V1 for emacs-devel@gnu.org; Thu, 27 Feb 2020 18:17:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7SPK-0002Yy-0W for emacs-devel@gnu.org; Thu, 27 Feb 2020 18:17:30 -0500 Original-Received: from ciao.gmane.io ([159.69.161.202]:33444) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j7SPJ-0002YO-RC for emacs-devel@gnu.org; Thu, 27 Feb 2020 18:17:29 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1j7SPH-000Pbk-Q5 for emacs-devel@gnu.org; Fri, 28 Feb 2020 00:17:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 159.69.161.202 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:245092 Archived-At: Mattias Engdegård writes: > 26 feb. 2020 kl. 23.38 skrev Eli Zaretskii : > >> Please revert these changes. I already said that I wasn't interested in making these regular expressions signal an error. > > Sorry Eli, I didn't realise it was a belief strongly held. The changes have been reverted, of course. > > But perhaps you will let me attempt to sway your opinion? I was a bit > lukewarm to the idea myself, but the irony was not lost on me after > making this very mistake in the implementation of code designed to > find regexp errors. In short, the check saves time for beginners and > experienced users alike, with no downside worth speaking about at all. > > There is no way a byte-compiler warning could come close to the > precision of a run-time check, and I speak with some modest experience > on the subject. A compiler warning wouldn't have found my error, nor > would it find common non-code use such as interactive search. > > Initially I was worried about someone's regexp-composing code falling > victim of a more stringent check, but Paul convinced me that this is > unlikely to be an actual concern. Besides, we do break absolute > compatibility now and then for good reasons, and this is one. There is > also GNU grep as a precedence. Okay, I'll be the one who says it: make it optional, disabled as default. This will nullify any concern about backwards compatibility and make it possible to test the feature on the field. Plus hopefully being useful for some of those that know about its existence.