bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36803: 27.0.50; Update mode-line of every window when compilation en


From: Stefan Monnier
Subject: bug#36803: 27.0.50; Update mode-line of every window when compilation ends
Date: Fri, 26 Jul 2019 09:59:39 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> > If my bisection is correct, then this regression dates back from
>> > 
>> >     645c8597e7f9fbc90ffe227d2be8ce383b0777ae
>> >     * src/process.c (status_notify): Avoid global redisplay (bug#11822)
>> >     
>> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=645c8597e7f9fbc90ffe227d2be8ce383b0777ae
>> 
>> Makes sense, I will look into why this change was made.
>
> Stefan, I'm looking and looking, and don't understand why that change
> made sense.  The process-status indication in the mode line is shown
> in all windows, so status_notify is exactly the place where we should
> trigger update of all mode lines.

Hmm... AFAIK the "process status" normally only indicates the status of
the process running in the buffer to which this mode line belongs.
Which is why I made the change to only bset_update_mode_line rather than
set the global update_mode_lines.

> Otherwise, we will have to sprinkle force-mode-line-update calls all
> over the place (and it still won't work well in the cases where the
> default sentinel is used, and this no Lisp is involved).

AFAIK it's rather rare to use a global indicator such that all mode
lines indicate whether that specific process might be running (and
I personally find it a bad idea: why should my hundreds of mode-lines
duplicate that information even though most of them are displaying
buffers which have nothing to do whatsoever with that process?).

So I think it's OK for this particular case to have to explicitly call
force-mode-line-update.  I don't think it will be needed "all over the
place".

Additionally, in this particular case, the need to update all mode-lines
doesn't come from the fact that a sentinel was run, but from the fact
that compilation-in-progress was modified, which can (and does) also
happen when no sentinel is run.  So I think TRT is something like the
patch below.


        Stefan


diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index a7575b5a1a..cbc60f5630 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1806,8 +1806,10 @@ compilation-start
                  ;; The process may have exited already.
                  (error nil)))
              (run-hook-with-args 'compilation-start-hook proc)
-              (setq compilation-in-progress
-                   (cons proc compilation-in-progress)))
+              ;; `compilation-in-progress' affects the mode-line of all
+              ;; buffers when it changes from nil to non-nil or vice-versa.
+              (unless compilation-in-progress (force-mode-line-update t))
+             (push proc compilation-in-progress))
          ;; No asynchronous processes available.
          (message "Executing `%s'..." command)
          ;; Fake mode line display as if `start-process' were run.
@@ -2240,7 +2242,10 @@ compilation-sentinel
            ;; process is dead, we can delete it now.  Otherwise it
            ;; will stay around until M-x list-processes.
            (delete-process proc)))
-       (setq compilation-in-progress (delq proc compilation-in-progress)))))
+        (setq compilation-in-progress (delq proc compilation-in-progress))
+        ;; `compilation-in-progress' affects the mode-line of all buffers when
+        ;; it changes from nil to non-nil or vice-versa.
+       (unless compilation-in-progress (force-mode-line-update t)))))
 
 (defun compilation-filter (proc string)
   "Process filter for compilation buffers.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]