GNU bug report logs - #36564
27.0.50; Wrong number of errors in compilation mode-line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36564 in the body.
You can then email your comments to 36564 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Wrong number of errors in compilation mode-line
Date: Tue, 09 Jul 2019 23:25:15 +0300

[Message part 1 (text/plain, inline)]

Often compilation-mode displays wrong number of errors
in the mode-line even when compilation is finished.

compilation-mode is based on font-lock, so when the
*compilation* buffer is not displayed during compilation,
some parts of this buffer that contain error messages
are not fontified, and thus these errors are not counted.

This patch ensures the correct number of errors
is displayed on the mode-line:

[compilation-handle-exit-font-lock-ensure.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 1a0d9bdbb7..a28e5f6068 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2179,6 +2182,8 @@ compilation-handle-exit
     ;; Prevent that message from being recognized as a compilation error.
     (add-text-properties omax (point)
 			 (append '(compilation-handle-exit t) nil))
+    ;; Update the number of errors in compilation-mode-line-errors
+    (font-lock-ensure)
     (setq mode-line-process
           (list
            (let ((out-string (format ":%s [%s]" process-status (cdr status)))

Message #8 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50;
 Wrong number of errors in compilation mode-line
Date: Thu, 11 Jul 2019 01:34:27 +0300

[Message part 1 (text/plain, inline)]

> Often compilation-mode displays wrong number of errors
> in the mode-line even when compilation is finished.
>
> compilation-mode is based on font-lock, so when the
> *compilation* buffer is not displayed during compilation,
> some parts of this buffer that contain error messages
> are not fontified, and thus these errors are not counted.
>
> This patch ensures the correct number of errors
> is displayed on the mode-line:

Actually maybe better to count errors not at the end
of compilation, but during compilation as output goes:

[compilation-font-lock-ensure.2.patch (text/x-diff, inline)]

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 1a0d9bdbb7..7b319e9947 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2245,6 +2250,8 @@ compilation-filter
               (unless comint-inhibit-carriage-motion
                 (comint-carriage-motion (process-mark proc) (point)))
               (set-marker (process-mark proc) (point))
+              ;; Update the number of errors in compilation-mode-line-errors
+              (font-lock-ensure compilation-filter-start (point))
               ;; (set (make-local-variable 'compilation-buffer-modtime)
               ;;      (current-time))
               (run-hooks 'compilation-filter-hook))

Message #11 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50;
 Wrong number of errors in compilation mode-line
Date: Fri, 12 Jul 2019 00:47:27 +0300

tags 36564 + patch fixed
found 36564 27.0.50
close 36564 27.0.50
quit

>> Often compilation-mode displays wrong number of errors
>> in the mode-line even when compilation is finished.
>>
>> compilation-mode is based on font-lock, so when the
>> *compilation* buffer is not displayed during compilation,
>> some parts of this buffer that contain error messages
>> are not fontified, and thus these errors are not counted.
>>
>> This patch ensures the correct number of errors
>> is displayed on the mode-line:
>
> Actually maybe better to count errors not at the end
> of compilation, but during compilation as output goes:

Fixed in master in ef6715364d.

Message #18 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50;
 Wrong number of errors in compilation mode-line
Date: Fri, 12 Jul 2019 01:02:27 +0300

[Message part 1 (text/plain, inline)]

>> Often compilation-mode displays wrong number of errors
>> in the mode-line even when compilation is finished.

BTW, there is another problem with notifications in the mode-line.
Recording devices have the record button identified by the red dot
to indicate active recording mode.  But in Emacs keyboard macro
recording is not highlighted in the mode-line and easy to miss.
This patch adds highlighting in the mode-line like on a recording device:

[defining-kbd-macro-red.patch (text/x-diff, inline)]

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 5205d497ef..64842c4e1f 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -655,11 +655,11 @@ minor-mode-alist
 (put 'minor-mode-alist 'risky-local-variable t)
 ;; Don't use purecopy here--some people want to change these strings.
 (setq minor-mode-alist
-      '((abbrev-mode " Abbrev")
+      `((abbrev-mode " Abbrev")
         (overwrite-mode overwrite-mode)
         (auto-fill-function " Fill")
         ;; not really a minor mode...
-        (defining-kbd-macro " Def")))
+        (defining-kbd-macro ,(propertize " Def" 'face 'error))))
 
 ;; These variables are used by autoloadable packages.
 ;; They are defined here so that they do not get overridden

Message #21 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50; Wrong number of errors in compilation
 mode-line
Date: Thu, 11 Jul 2019 18:32:10 -0400

> --- a/lisp/progmodes/compile.el
> +++ b/lisp/progmodes/compile.el
> @@ -2245,6 +2250,8 @@ compilation-filter
>                (unless comint-inhibit-carriage-motion
>                  (comint-carriage-motion (process-mark proc) (point)))
>                (set-marker (process-mark proc) (point))
> +              ;; Update the number of errors in compilation-mode-line-errors
> +              (font-lock-ensure compilation-filter-start (point))

I worry that doing it there will slow down processing too much.
But even if we want to do it there, I think font-lock-ensure is wrong
because we shouldn't *highlight* (e.g. the user may prefer font-lock to
be disabled).

Does compilation--ensure-parse do what you want?


        Stefan

Message #24 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50; Wrong number of errors in compilation
 mode-line
Date: Fri, 12 Jul 2019 21:57:29 +0300

>> --- a/lisp/progmodes/compile.el
>> +++ b/lisp/progmodes/compile.el
>> @@ -2245,6 +2250,8 @@ compilation-filter
>>                (unless comint-inhibit-carriage-motion
>>                  (comint-carriage-motion (process-mark proc) (point)))
>>                (set-marker (process-mark proc) (point))
>> +              ;; Update the number of errors in compilation-mode-line-errors
>> +              (font-lock-ensure compilation-filter-start (point))
>
> I worry that doing it there will slow down processing too much.
> But even if we want to do it there, I think font-lock-ensure is wrong
> because we shouldn't *highlight* (e.g. the user may prefer font-lock to
> be disabled).
>
> Does compilation--ensure-parse do what you want?

I tried compilation--ensure-parse, and it updates the number of errors,
so I replaced font-lock-ensure with compilation--ensure-parse.

Message #27 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50;
 Wrong number of errors in compilation mode-line
Date: Fri, 12 Jul 2019 16:09:24 -0400

> I tried compilation--ensure-parse, and it updates the number of errors,
> so I replaced font-lock-ensure with compilation--ensure-parse.

Thanks, that's much better.
I'm still worried about the performance cost of running
compilation--ensure-parse every time we get a few chars from the
process filter.

Not sure how/where to delay it, tho.  Maybe some idle timer?


        Stefan

Message #30 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50; Wrong number of errors in compilation
 mode-line
Date: Sun, 14 Jul 2019 01:04:25 +0300

>> I tried compilation--ensure-parse, and it updates the number of errors,
>> so I replaced font-lock-ensure with compilation--ensure-parse.
>
> Thanks, that's much better.
> I'm still worried about the performance cost of running
> compilation--ensure-parse every time we get a few chars from the
> process filter.
>
> Not sure how/where to delay it, tho.  Maybe some idle timer?

IIUC, after adding compilation--ensure-parse there is no
performance degradation in case when the compilation buffer
is displayed during compilation, because compilation--ensure-parse
is called on the same-sized chunks as when the buffer is fontified
by font-lock.

I noticed this when tried to debug the problem of fontifying
diff hunks, but I failed to find a solution.  The problem is this:
sometimes diff-mode doesn't refine some hunks during font-lock
when the first part of the hunk emitted by diff-process-filter
(from the diff command comparing files) is fontified partly,
then after emitting the remaining part of the hunk it remains
unfontified.

Message #33 received at 36564 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36564 <at> debbugs.gnu.org
Subject: Re: bug#36564: 27.0.50;
 Wrong number of errors in compilation mode-line
Date: Mon, 15 Jul 2019 08:44:21 -0400

> IIUC, after adding compilation--ensure-parse there is no
> performance degradation in case when the compilation buffer
> is displayed during compilation, because compilation--ensure-parse
> is called on the same-sized chunks as when the buffer is fontified
> by font-lock.

Only when the window displays the bottom of the buffer.

> I noticed this when tried to debug the problem of fontifying
> diff hunks, but I failed to find a solution.  The problem is this:
> sometimes diff-mode doesn't refine some hunks during font-lock
> when the first part of the hunk emitted by diff-process-filter
> (from the diff command comparing files) is fontified partly,
> then after emitting the remaining part of the hunk it remains
> unfontified.

Yes, it's a bit tricky to handle this right while at the same time
trying to avoid refontifying the same hunk N times (where N is
proportional to the hunk size).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.