bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: compilation-handle-exit-font-lock-ensure.patch --]
[-- Type: text/x-diff, Size: 592 bytes --]

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)))

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: compilation-font-lock-ensure.2.patch --]
[-- Type: text/x-diff, Size: 699 bytes --]

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))

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

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.

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

>> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: defining-kbd-macro-red.patch --]
[-- Type: text/x-diff, Size: 721 bytes --]

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

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Stefan Monnier]

> --- 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

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

>> --- 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.

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Stefan Monnier]

> 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

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Juri Linkov]

>> 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.

bug#36564: 27.0.50; Wrong number of errors in compilation mode-line

[Stefan Monnier]

> 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