From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: :alnum: broken? Date: Fri, 28 Feb 2020 10:09:41 +0200 Message-ID: <837e07gmka.fsf@gnu.org> 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="76347"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 28 09:10:29 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 1j7aj7-000JlB-N8 for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Feb 2020 09:10:29 +0100 Original-Received: from localhost ([::1]:43322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7aj6-0002i0-Of for ged-emacs-devel@m.gmane-mx.org; Fri, 28 Feb 2020 03:10:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41127) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7aib-0002EL-Th for emacs-devel@gnu.org; Fri, 28 Feb 2020 03:09:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j7aib-0002Kb-5H; Fri, 28 Feb 2020 03:09:57 -0500 Original-Received: from [176.228.60.248] (port=2138 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j7aia-0000o1-GY; Fri, 28 Feb 2020 03:09:56 -0500 In-reply-to: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Thu, 27 Feb 2020 18:57:50 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:245096 Archived-At: > From: Mattias Engdegård > Date: Thu, 27 Feb 2020 18:57:50 +0100 > Cc: emacs-devel@gnu.org, > Clément Pit-Claudel , > Paul Eggert > > > 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. Thank you. > 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. I see you POV, and understand it. Granted, years ago, when these classes were introduced, I had my share of "forget the brackets" mistake. But I don't believe it is right for us to reject questionable but valid code. This is a job for linters and for special warning options, used by those who want this and don't mind extra level of noise and annoyances. That's why doing this in the byte compiler sounds like a good solution to me. I can even agree to reject this at run time under a non-default value of some special variable (a moral equivalent of a compiler warning option). But doing this by default is simply wrong, IMO, the precedent of GCC and other compilers that become noisier and noisier with each release notwithstanding. Thanks.