Re: Scan of regexp mistakes

[Mattias Engdegård]

8 mars 2019 kl. 18.13 skrev Paul Eggert <address@hidden>:
> 
> On 3/5/19 7:06 AM, Mattias Engdegård wrote:
>> 
>> I can run it periodically but would surely forget. Should I put the trawler 
>> in the Emacs source tree (if so, where?), in ELPA, or elsewhere?
> 
> Stefan mentioned one possibility. Though even then I daresay it'd be
> helpful if you ran it periodically, just as I periodically run
> admin/merge-gnulib. (If you don't run it, it's likely nobody else will....)

You are both right. I shall try to run it periodically but also see if it can 
be integrated into `make check'.
It depends on an ELPA package (xr); does this require any special treatment? We 
don't want `make check' to fail if xr isn't installed.

Thanks for your updates, and I agree with your changes.

>>       (replace-regexp-in-string "[\000-\032\177<>#%\"{}|\\^[]`%?;]"
>> 
>> That \032 doesn't look right (number base confusion?), and it looks like 
>> it's meant as a single character alternative but it isn't, given the 
>> misplaced `]'.
> 
> The regexp has other troubles. It doesn't include !$'()*+,/:@&= (all of
> which are reserved characters according to RFC 3986), and it has
> duplicate %. The attached patch fixes the % and puts in a FIXME about
> the other chars.

Thank you. It annoyed me that I couldn't catch this regexp with any formal rule 
violation (maybe we should try tax evasion). An ad-hoc pattern to catch 
[...[...]...] did work, and caught nothing else, but I was afraid it would 
become a false positive in legitimate patterns.

>> --- a/lisp/progmodes/fortran.el
>> +++ b/lisp/progmodes/fortran.el
>> @@ -2052,7 +2052,7 @@ If ALL is nil, only match comments that start in 
>> column > 0."
>>                 (when (<= (point) bos)
>>                   (move-to-column (1+ fill-column))
>>                   ;; What is this doing???
>> -                  (or (re-search-forward "[\t\n,'+-/*)=]" eol t)
>> +                  (or (re-search-forward "[-\t\n,'+./*)=]" eol t)
>> 
>> Where did the . come from? Don't you think that `+-/*' were meant to include 
>> those four symbols only?
> 
> I couldn't figure out what the code was doing (note the comment...) so
> decided to preserve the semantics of the old regexp. But you're right,
> "." is likely not intended there. I removed it in the attached.

It appears to look for the first good place to desperately break a line that is 
already indented beyond the margin, using a convention of breaking after binary 
operators. From this point of view, excluding . is probably correct, lest we 
split .EQ. . I can't really explain the "\t\n')" part; in particular, the 
search bound should make it impossible for \n to match. It still mangles some 
things: for instance,

  ALPHA**BETA

is line-broken as

  ALPHA*
  *BETA

Thus we might want to improve the regexp to (rx (or "**" (any 
"\t\n,')=*/+-"))), but we should really ask a Fortran expert.