emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: :alnum: broken?


From: Eli Zaretskii
Subject: Re: :alnum: broken?
Date: Fri, 28 Feb 2020 10:09:41 +0200

> From: Mattias Engdegård <address@hidden>
> Date: Thu, 27 Feb 2020 18:57:50 +0100
> Cc: address@hidden,
>         Clément Pit-Claudel <address@hidden>,
>         Paul Eggert <address@hidden>
> 
> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]