emacs-devel
[Top][All Lists]
Advanced

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

Re: Forbid reverse ranges in rx


From: Mattias Engdegård
Subject: Re: Forbid reverse ranges in rx
Date: Tue, 12 Mar 2019 16:26:23 +0100
User-agent: Evolution 3.30.5 (3.30.5-1.fc29)

tis 2019-03-12 klockan 10:27 -0400 skrev Clément Pit-Claudel:
> I worry that maybe we should make this a warning, rather than an
> error, since there are lots of poorly supported but decently working
> Emacs modes out there.  This change will make some of these (subtly
> broken) modes unusable (we've seen that e.g. the change to comint
> caused some breakage, so I think we should be especially careful). 

The risk of breaking anything should be substantially lower for rx,
since reverse ranges are less likely to occur by accident than in
string regexps, and because rx is just much less frequently used.

> I'd love to see all these errors detected by xr as warnings in the
> byte-compiler.

I don't want to make a separate linter for rx; it should protect its
own abstractions. That's another reason for the change: we don't want
to end up with lots of ill-defined syntax and semantics that cannot be
changed for legacy reasons.

For that matter, the latest version of trawl does evaluate most rx
forms that are used as regexps, so rx errors there stand a good chance
of being detected.

> Also, if we make this an error in rx, should we also make it an error
> in regular regexps?

I would like to, but as you say there is lots of code that work well
enough despite little mistakes. There is also wilful abuse: auctex uses
[^z-a] as "any character".

> > +                      (error "Reverse range `%c-%c' in Rx `any'
> > not permitted"
> > +                             start end)))
> 
> Consider rephrasing this to explain why it's not permitted (maybe "…
> no permitted, as it does not match anything").

Do we really need to mention the legacy semantics, which were
accidental and arbitrary? "Z-A" is disallowed because it doesn't make
sense, not because of what happened before we thought of checking.





reply via email to

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