Subject: bug#34479: closed (Re: bug#34479: Incorrect classification of messages in compilation-mode buffer)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 15 Feb 2019 08:03:02 +0000

Your bug report

#34479: Incorrect classification of messages in compilation-mode buffer

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
34479: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34479
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#34479: Incorrect classification of messages in compilation-mode buffer
From: Eli Zaretskii <[email-masked]>
To: Daniel Lopez <[email-masked]>
Cc: [email-masked]
Date: Fri, 15 Feb 2019 10:02:19 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Daniel Lopez <[email-masked]>
> Date: Thu, 14 Feb 2019 16:05:10 +0000
> 
> Argh, I forgot to attach the patch. Here it is!

Thanks.  This is a relatively recent regression, so I pushed it to the
emacs-26 branch.

Please in the future include a ChangeLog-style commit log message with
your patches.

Subject: Incorrect classification of messages in compilation-mode buffer
From: Daniel Lopez <[email-masked]>
To: [email-masked]
Date: Thu, 14 Feb 2019 16:00:08 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Reproduce:

- Open the attached test program compilation_test.c in Emacs
- M-x compile
- Enter compile command "gcc -c compilation_test.c"

In the resulting *compilation* buffer, there should be a mixture of 
"error", "warning" and "note" messages. Trouble is they're all parsed as 
errors - hence they're all coloured in red, and querying any one's type 
by moving point onto it and evaluating "(compilation--message->type 
(get-text-property (point) 'compilation-message))" always returns 2, 
though warnings should return 1 and notes should return 0. Commands that 
jump between previous/next error also behave correspondingly wrongly.

Fix:

The attached fix_compilation_message_type.patch, applied to Git master, 
fixes it for me.

It seems like the old code was accidentally using the same variable for 
the TYPE field of the current rule from compilation-error-regexp-alist, 
and in an inner loop, the actual type that the current message from the 
compilation buffer was resolved to be, so the resolved type of the first 
message tends to get carried down into the following ones.

Daniel