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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
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:


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)))
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
> 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:


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))
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Juri Linkov-2
>> 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:


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
Reply | Threaded
Open this post in threaded view
|

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

Stefan Monnier
In reply to this post by Juri Linkov-2
> --- 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




Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> --- 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.



Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> 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.



Reply | Threaded
Open this post in threaded view
|

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