GNU bug report logs -
#40119
[PATCH] Make compilation-mode regexp matching case-sensitive
Previous Next
Reported by: Mattias Engdegård <mattiase <at> acm.org>
Date: Wed, 18 Mar 2020 15:32:01 UTC
Severity: normal
Tags: patch
Done: Mattias Engdegård <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40119 in the body.
You can then email your comments to 40119 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 18 Mar 2020 15:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mattias Engdegård <mattiase <at> acm.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 18 Mar 2020 15:32:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Since the regexps being matched in compilation-mode are numerous, independently written, and often intersect, it makes sense to use case-sensitive matching. After all, compiler messages do not change case between runs.
Doing so improves performance: case-insensitive matching is slightly slower and stricter matching allows for earlier rejection. It also reduces collisions, and it is probably what everybody assumed anyway.
[0001-Make-compilation-mode-regexp-matching-case-sensitive.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 18 Mar 2020 18:06:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 40119 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 18 Mar 2020 16:31:49 +0100
>
> +** Compilation mode
> +
> +*** Regexp matching of messages is now case-sensitive.
> +
>
> * New Modes and Packages in Emacs 28.1
>
> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
> index 455f181f50..aefaa1707a 100644
> --- a/lisp/progmodes/compile.el
> +++ b/lisp/progmodes/compile.el
> @@ -1435,7 +1435,8 @@ compilation-parse-errors
> (if (symbolp item)
> (setq item (cdr (assq item
> compilation-error-regexp-alist-alist))))
> - (let ((file (nth 1 item))
> + (let ((case-fold-search nil)
> + (file (nth 1 item))
> (line (nth 2 item))
> (col (nth 3 item))
> (type (nth 4 item))
What if we are wrong and some compiler needs case-insensitive
matching? Your change makes it impossible to get back the old
behavior, not even optionally.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 18 Mar 2020 18:31:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 40119 <at> debbugs.gnu.org (full text, mbox):
18 mars 2020 kl. 19.05 skrev Eli Zaretskii <eliz <at> gnu.org>:
> What if we are wrong and some compiler needs case-insensitive
> matching? Your change makes it impossible to get back the old
> behavior, not even optionally.
Do you mean that we should add a defcustom to permit the user to control the behaviour, or that doing so is impossible once rules are added which rely on the case-sensitivity?
Either way, it seems much more likely that it is case-insensitivity that is an obstacle to adding new rules, not the contrary. Could you give an example of what such a hypothetical compiler needing case-insensitive matching would look like?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 18 Mar 2020 19:30:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 40119 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 18 Mar 2020 19:30:23 +0100
> Cc: 40119 <at> debbugs.gnu.org
>
> 18 mars 2020 kl. 19.05 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > What if we are wrong and some compiler needs case-insensitive
> > matching? Your change makes it impossible to get back the old
> > behavior, not even optionally.
>
> Do you mean that we should add a defcustom to permit the user to control the behaviour, or that doing so is impossible once rules are added which rely on the case-sensitivity?
The former.
> Either way, it seems much more likely that it is case-insensitivity that is an obstacle to adding new rules, not the contrary.
I don't understand what adding new rules has to do with this. I'm
talking about a specific rule that needs to be matched
case-insensitively.
> Could you give an example of what such a hypothetical compiler needing case-insensitive matching would look like?
Sorry, I don't understand the question. What I meant is that some of
the rules were written _knowing_ that the match is case-insensitive,
and will fail to match if that is changed. I don't think there's
anyone around here that can claim detailed knowledge of every rule and
the compiler(s) that use them, so we have no one to ask whether this
danger is real or imaginary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 18 Mar 2020 22:06:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 40119 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
18 mars 2020 kl. 20.29 skrev Eli Zaretskii <eliz <at> gnu.org>:
> What I meant is that some of
> the rules were written _knowing_ that the match is case-insensitive,
> and will fail to match if that is changed. I don't think there's
> anyone around here that can claim detailed knowledge of every rule and
> the compiler(s) that use them, so we have no one to ask whether this
> danger is real or imaginary.
Thank you for clarifying! All the tests pass after the change, and etc/compilation.txt is rendered almost identically. There is only one difference: the example for 'watcom' did not actually match that rule, but rule 'edg-1' (which comes earlier in the list) instead. With case-fold-search set to nil, the 'watcom' example is matched by its rule and not by edg-1.
In other words, it is unlikely that the existing rules in compile.el expect case-insensitive matching of the output for which they are written. Conversely, there is already evidence that case-insensitive matching causes the wrong rule to be used.
Of course we cannot exclude that rules are used with compilers other than for which the patterns were designed. The correct way to handle this should be to add a suitable rule, not to change how all rules match. Nevertheless, I added a user switch to turn case-insensitivity back on again for those who prefer it that way.
Revised patch follows.
[0001-Make-compilation-mode-regexp-matching-case-sensitive.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 25 Mar 2020 20:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 40119 <at> debbugs.gnu.org (full text, mbox):
No objections detected -- patch pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#40119
; Package
emacs
.
(Wed, 25 Mar 2020 20:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 40119 <at> debbugs.gnu.org (full text, mbox):
On 18.03.2020 21:29, Eli Zaretskii wrote:
> What I meant is that some of
> the rules were written_knowing_ that the match is case-insensitive,
> and will fail to match if that is changed.
Suppose some author discovers that about one of their rules (or
several). Would it be too hard to fix those rules instead of changing
the user option?
Because said variable can affect all other rules as well. And other
compilation modes, if used incorrectly.
bug closed, send any further explanations to
40119 <at> debbugs.gnu.org and Mattias Engdegård <mattiase <at> acm.org>
Request was from
Mattias Engdegård <mattiase <at> acm.org>
to
control <at> debbugs.gnu.org
.
(Tue, 07 Apr 2020 13:17:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 06 May 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.