all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 36803@debbugs.gnu.org, larsi@gnus.org, kevin.legouguec@gmail.com
Subject: bug#36803: 27.0.50; Update mode-line of every window when compilation ends
Date: Fri, 26 Jul 2019 09:59:39 -0400	[thread overview]
Message-ID: <jwvftmsq5b2.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83r26dmcx3.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Jul 2019 11:13:12 +0300")

>> > 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	other threads:[~2019-07-26 13:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 21:22 bug#36803: 27.0.50; Update mode-line of every window when compilation ends Kévin Le Gouguec
2019-07-25  9:42 ` Lars Ingebrigtsen
2019-07-25 10:34   ` Eli Zaretskii
2019-07-25 13:37     ` Kévin Le Gouguec
2019-07-25 14:59       ` Eli Zaretskii
2019-07-26  8:13         ` Eli Zaretskii
2019-07-26 13:59           ` Stefan Monnier [this message]
2019-07-26 15:08             ` Eli Zaretskii
2019-07-26 16:23               ` Stefan Monnier
2019-07-26 18:16                 ` Eli Zaretskii
2019-07-26 18:53                   ` Stefan Monnier
2019-07-26 19:21                     ` Eli Zaretskii
2019-07-26 19:35                       ` Lars Ingebrigtsen
2019-07-26 21:26                         ` Kévin Le Gouguec
2019-07-27  9:53                           ` Lars Ingebrigtsen
2019-07-27 17:01                             ` Kévin Le Gouguec
2019-07-27  6:57                         ` Eli Zaretskii
2019-07-26 21:10                       ` Stefan Monnier
2019-07-27  7:46                         ` Eli Zaretskii
2019-07-27 12:46                           ` Stefan Monnier
2019-07-27 13:12                             ` Eli Zaretskii
2019-07-27 14:00                               ` Stefan Monnier
2019-07-27 17:37                                 ` Kévin Le Gouguec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvftmsq5b2.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=36803@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=kevin.legouguec@gmail.com \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.