Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

[Stefan Monnier]

>     Postfix ops are literal after ^ but not after \(?:^\)

BTW, some of those details of the syntax of regexps are really
undesirable.  Would it be possible for xr to flag them somehow to try
and discourage their use?

Of course, even better would be to flag such uses not only in xr but
more generally.  I'm thinking for example of a regexp that starts with
a postfix operator or that backslash-escapes a non-special character.


        Stefan

Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

[Mattias Engdegård]

19 feb. 2019 kl. 21.29 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:
> 
>>    Postfix ops are literal after ^ but not after \(?:^\)
> 
> BTW, some of those details of the syntax of regexps are really
> undesirable.  Would it be possible for xr to flag them somehow to try
> and discourage their use?
> 
> Of course, even better would be to flag such uses not only in xr but
> more generally.  I'm thinking for example of a regexp that starts with
> a postfix operator or that backslash-escapes a non-special character.

The xr machinery could probably be reused for that sort of linting, yes, but whether it's a good place depends on how we want to use it. It could be used in static linting of regexps in elisp string literals, but with false positives and negatives. Putting it in regex-emacs.c would allow for exact detection but only of those actually used during execution.

By the way, the reason for fixing this rather minor bug in xr, apart from general perfectionism, was a bug in rx: bol and eol are unconditionally translated to ^ and $ no matter where they occur. For example:

(rx "a" bol "b" eol "c")
=>
"a^b$c"  (which means literally "a^b$c")

(rx (zero-or-more bol))
=>
"^*"     (which means literally "^*")

rx should bracket the ^$ stuff and generate something like "a\\(?:^\\)b\\(?:$\\)c" and "\\(?:^\\)*".

Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

[Mattias Engdegård]

19 feb. 2019 kl. 21.29 skrev Stefan Monnier <monnier@IRO.UMontreal.CA>:
> 
>>    Postfix ops are literal after ^ but not after \(?:^\)
> 
> BTW, some of those details of the syntax of regexps are really
> undesirable.  Would it be possible for xr to flag them somehow to try
> and discourage their use?

Now xr has `xr-lint'. Was that what you had in mind?

Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

[Stefan Monnier]

>>>    Postfix ops are literal after ^ but not after \(?:^\)
>> BTW, some of those details of the syntax of regexps are really
>> undesirable.  Would it be possible for xr to flag them somehow to try
>> and discourage their use?
> Now xr has `xr-lint'. Was that what you had in mind?

Yes, the patch looked great: simple to implement but return thorough info.
The next question will be how/where to hook it.

Maybe we could setup a flymake backend which looks for (defcustom ... "...")
and things like (re-search-forward "..."), tho maybe hooking it into the
byte-compiler is a better option (that will also make it work with
flymake)


        Stefan

Re: [elpa] externals/xr e77aa97: Postfix ops are literal after ^ but not after \(?:^\)

[Mattias Engdegård]

21 feb. 2019 kl. 02.35 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
> Yes, the patch looked great: simple to implement but return thorough info.
> The next question will be how/where to hook it.
> 
> Maybe we could setup a flymake backend which looks for (defcustom ... "...")
> and things like (re-search-forward "..."), tho maybe hooking it into the
> byte-compiler is a better option (that will also make it work with
> flymake)

I'll let that for others to do then -- I just wrote a throwaway thing to scan the Emacs sources and got about 150 complaints, some of which very much look like bugs.

Complaining about \] didn't seem very productive so that particular warning went away, since it is common to match square brackets in pairs and [ needs to be escaped. There is also a new repetition-of-repetition check.