unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: cpitclaudel@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: :alnum: broken?
Date: Fri, 28 Feb 2020 10:09:41 +0200	[thread overview]
Message-ID: <837e07gmka.fsf@gnu.org> (raw)
In-Reply-To: <E56CA4D1-D891-4D17-B85B-F4DEDF113E83@acm.org> (message from Mattias Engdegård on Thu, 27 Feb 2020 18:57:50 +0100)

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 27 Feb 2020 18:57:50 +0100
> Cc: emacs-devel@gnu.org,
>         Clément Pit-Claudel <cpitclaudel@gmail.com>,
>         Paul Eggert <eggert@cs.ucla.edu>
> 
> > 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.



  parent reply	other threads:[~2020-02-28  8:09 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 18:58 :alnum: broken? Stephen Leake
2020-02-21 19:00 ` Paul Eggert
2020-02-21 19:32   ` Mattias Engdegård
2020-02-21 21:28   ` Stephen Leake
2020-02-22  1:09     ` Paul Eggert
2020-02-22  7:48       ` Eli Zaretskii
2020-02-22 21:28         ` Paul Eggert
2020-02-23  3:28           ` Eli Zaretskii
2020-02-23 10:21       ` Mattias Engdegård
2020-02-23 18:13         ` Paul Eggert
2020-02-23 18:27           ` Eli Zaretskii
2020-02-23 19:34             ` Óscar Fuentes
2020-02-23 22:12               ` Drew Adams
2020-02-25  3:57                 ` Richard Stallman
2020-02-25 14:37                   ` Stefan Monnier
2020-02-25 15:45                     ` Drew Adams
2020-02-25 15:40                   ` Drew Adams
2020-02-25  9:33                 ` Andreas Schwab
2020-02-25 13:53                   ` Clément Pit-Claudel
2020-02-25 15:40                   ` Drew Adams
2020-02-23 18:40           ` Mattias Engdegård
2020-02-26 14:10           ` Mattias Engdegård
2020-02-26 14:54             ` Drew Adams
2020-02-26 15:48             ` Stefan Monnier
2020-02-26 21:00               ` Paul Eggert
2020-02-26 21:18                 ` Mattias Engdegård
2020-02-26 21:24                   ` Clément Pit-Claudel
2020-02-26 22:01                     ` Mattias Engdegård
2020-02-26 22:38                       ` Eli Zaretskii
2020-02-27 17:57                         ` Mattias Engdegård
2020-02-27 23:17                           ` Óscar Fuentes
2020-02-28  8:09                           ` Eli Zaretskii [this message]
2020-02-28  8:48                             ` Paul Eggert
2020-02-28 13:11                               ` Eli Zaretskii
2020-02-28 17:41                                 ` Paul Eggert
2020-02-28 20:09                                   ` Eli Zaretskii
2020-02-28 20:25                                     ` Paul Eggert
2020-02-28 20:38                                       ` Eli Zaretskii
2020-02-28 21:04                                         ` Mattias Engdegård
2020-02-28 21:40                                           ` Eli Zaretskii
2020-02-29 11:43                                             ` Mattias Engdegård
2020-02-29 12:07                                               ` Eli Zaretskii
2020-02-29 14:24                                                 ` Stefan Monnier
2020-02-29 14:14                                               ` Stefan Monnier
2020-02-29 17:33                                                 ` Óscar Fuentes
2020-02-29 19:52                                                   ` Stefan Monnier
2020-02-29 21:12                                                     ` Óscar Fuentes
2020-02-29 22:22                                                       ` Marcin Borkowski
2020-02-29 22:34                                                         ` Clément Pit-Claudel
2020-03-01 22:44                                                           ` Marcin Borkowski
2020-03-02  3:07                                                             ` Stefan Monnier
2020-03-02  7:15                                                               ` Marcin Borkowski
2020-03-02  7:41                                                                 ` Emanuel Berg via Emacs development discussions.
2020-03-02 16:14                                                                   ` Drew Adams
2020-03-02 16:51                                                                     ` Emanuel Berg via Emacs development discussions.
2020-03-02  7:56                                                                 ` Joost Kremers
2020-03-02  9:44                                                                   ` Štěpán Němec
2020-03-02 10:43                                                                     ` Joost Kremers
2020-03-02 13:37                                                                 ` Clément Pit-Claudel
2020-03-02 17:03                                                                 ` Stefan Monnier
2020-03-02 18:23                                                                   ` Clément Pit-Claudel
2020-02-29 23:02                                                         ` Andrea Corallo
2020-03-01 22:41                                                           ` Marcin Borkowski
2020-02-29 22:58                                                       ` Stefan Monnier
2020-02-29 23:28                                                         ` Óscar Fuentes
2020-02-27  1:33                       ` Paul Eggert
2020-02-26 16:01             ` Andreas Schwab
2020-02-26 21:06               ` Mattias Engdegård
2020-02-27  8:43                 ` Andreas Schwab
2020-02-27 18:05                   ` Mattias Engdegård
2020-02-22  9:09     ` Eli Zaretskii
2020-02-23  3:49     ` Richard Stallman
2020-02-23  7:51       ` Paul Eggert
2020-02-23 15:07         ` Eli Zaretskii
2020-02-21 19:01 ` Noam Postavsky
2020-02-21 19:04 ` Andreas Schwab
     [not found] <<86wo8flqct.fsf@stephe-leake.org>
     [not found] ` <<f89e340f-9a19-50e1-4421-57fd3e235548@cs.ucla.edu>
     [not found]   ` <<86sgj3ljf0.fsf@stephe-leake.org>
     [not found]     ` <<E1j5iGS-0000r6-Id@fencepost.gnu.org>
     [not found]       ` <<18bd2b64-1c2f-055f-4fa0-092bdb1da531@cs.ucla.edu>
     [not found]         ` <<838sktibpu.fsf@gnu.org>
2020-02-23 16:52           ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837e07gmka.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=cpitclaudel@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=mattiase@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).