* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
@ 2019-07-09 20:25 Juri Linkov
2019-07-10 22:34 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2019-07-09 20:25 UTC (permalink / raw)
To: 36564
[-- 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)))
^ permalink raw reply related [flat|nested] 9+ messages in thread* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-09 20:25 bug#36564: 27.0.50; Wrong number of errors in compilation mode-line Juri Linkov
@ 2019-07-10 22:34 ` Juri Linkov
2019-07-11 21:47 ` Juri Linkov
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Juri Linkov @ 2019-07-10 22:34 UTC (permalink / raw)
To: 36564
[-- 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))
^ permalink raw reply related [flat|nested] 9+ messages in thread* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-10 22:34 ` Juri Linkov
@ 2019-07-11 21:47 ` Juri Linkov
2019-07-11 22:02 ` Juri Linkov
2019-07-11 22:32 ` Stefan Monnier
2 siblings, 0 replies; 9+ messages in thread
From: Juri Linkov @ 2019-07-11 21:47 UTC (permalink / raw)
To: 36564
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-10 22:34 ` Juri Linkov
2019-07-11 21:47 ` Juri Linkov
@ 2019-07-11 22:02 ` Juri Linkov
2019-07-11 22:32 ` Stefan Monnier
2 siblings, 0 replies; 9+ messages in thread
From: Juri Linkov @ 2019-07-11 22:02 UTC (permalink / raw)
To: 36564
[-- 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
^ permalink raw reply related [flat|nested] 9+ messages in thread* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-10 22:34 ` Juri Linkov
2019-07-11 21:47 ` Juri Linkov
2019-07-11 22:02 ` Juri Linkov
@ 2019-07-11 22:32 ` Stefan Monnier
2019-07-12 18:57 ` Juri Linkov
2 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2019-07-11 22:32 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36564
> --- 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
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-11 22:32 ` Stefan Monnier
@ 2019-07-12 18:57 ` Juri Linkov
2019-07-12 20:09 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2019-07-12 18:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 36564
>> --- 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-12 18:57 ` Juri Linkov
@ 2019-07-12 20:09 ` Stefan Monnier
2019-07-13 22:04 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2019-07-12 20:09 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36564
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-12 20:09 ` Stefan Monnier
@ 2019-07-13 22:04 ` Juri Linkov
2019-07-15 12:44 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2019-07-13 22:04 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 36564
>> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#36564: 27.0.50; Wrong number of errors in compilation mode-line
2019-07-13 22:04 ` Juri Linkov
@ 2019-07-15 12:44 ` Stefan Monnier
0 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2019-07-15 12:44 UTC (permalink / raw)
To: Juri Linkov; +Cc: 36564
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-15 12:44 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-09 20:25 bug#36564: 27.0.50; Wrong number of errors in compilation mode-line Juri Linkov
2019-07-10 22:34 ` Juri Linkov
2019-07-11 21:47 ` Juri Linkov
2019-07-11 22:02 ` Juri Linkov
2019-07-11 22:32 ` Stefan Monnier
2019-07-12 18:57 ` Juri Linkov
2019-07-12 20:09 ` Stefan Monnier
2019-07-13 22:04 ` Juri Linkov
2019-07-15 12:44 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).