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

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

[Kévin Le Gouguec]

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

Hello,

The recent changes on the compilation-in-progress indicator[1] made me
realize that the indicator lingers in the mode-lines of some windows.
To reproduce from emacs -Q:

    C-x 2
    C-x 2
    M-x compile RET C-a C-k true RET

"[Compiling]" correctly disappears from the current window and the
compilation window, but it lingers on the mode-line of the third window.

The attached patch trivially fixes the issue; I do not know whether it's
appropriate, or maybe too heavyweight.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Update-every-mode-line-when-compilation-ends.patch --]
[-- Type: text/x-patch, Size: 1042 bytes --]

From 25bc31d85ffd7e27e00ba73bac47856def9e97ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= <kevin.legouguec@gmail.com>
Date: Wed, 24 Jul 2019 22:50:59 +0200
Subject: [PATCH] Update every mode-line when compilation ends

Otherwise the "[Compiling]" indicator lingers in some of them.

* lisp/progmodes/compile.el (compilation-handle-exit): Refresh
every mode-line.
---
 lisp/progmodes/compile.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index f4750c0059..657650b488 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2214,7 +2214,7 @@ compilation-handle-exit
                                  'compilation-mode-line-exit)))
            compilation-mode-line-errors))
     ;; Force mode line redisplay soon.
-    (force-mode-line-update)
+    (force-mode-line-update t)
     (if (and opoint (< opoint omax))
 	(goto-char opoint))
     (run-hook-with-args 'compilation-finish-functions cur-buffer msg)))
-- 
2.22.0


[-- Attachment #3: Type: text/plain, Size: 5268 bytes --]


WDYT?


[1] Make "Compiling" in the mode line a clickable command
    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3479ec7332a474b3400cbc6b681c2a1f5637db94


In GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.9, cairo version 1.16.0)
 of 2019-07-03 built on my-little-tumbleweed
Repository revision: 22760ab357dd8124c856b76a545e562917872d78
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: openSUSE Tumbleweed

Configured using:
 'configure --with-xwidgets --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS XWIDGETS JSON PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Magit

Minor modes in effect:
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  minibuffer-depth-indicate-mode: t
  icomplete-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  electric-pair-mode: t
  diff-hl-flydiff-mode: t
  global-diff-hl-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr magit-patch bug-reference gnus-async qp gnus-ml
nndraft nnmh nnfolder utf-7 epa-file gnutls network-stream nsm
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range
gnus-win gnus nnheader emacsbug sendmail magit-extras flyspell ispell
rect thingatpt magit-submodule magit-obsolete magit-popup magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process magit-mode transient git-commit magit-git magit-section
magit-utils crm log-edit message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
with-editor async-bytecomp async server dash executable cus-edit
wid-edit whitespace eieio-opt speedbar sb-image ezimage dframe shell
pcomplete help-fns radix-tree cl-print debug backtrace find-func
misearch multi-isearch vc-git files-x pcase rx delight advice
eighters-theme cl-extra rg rg-ibuffer rg-result wgrep-rg wgrep s
rg-history rg-header rg-compat ibuf-ext ibuffer ibuffer-loaddefs grep
compile comint ansi-color ring quail help-mode edmacro kmacro disp-table
paren mb-depth icomplete page-break-lines elec-pair diff-hl-flydiff diff
diff-hl vc-dir ewoc vc vc-dispatcher diff-mode easy-mmode delsel
cus-start cus-load mule-util info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 285991 35395)
 (symbols 48 25540 1)
 (strings 32 82326 4257)
 (string-bytes 1 2726046)
 (vectors 16 48859)
 (vector-slots 8 1366992 49654)
 (floats 8 259 339)
 (intervals 56 4124 4946)
 (buffers 992 32))

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

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> The recent changes on the compilation-in-progress indicator[1] made me
> realize that the indicator lingers in the mode-lines of some windows.
> To reproduce from emacs -Q:
>
>     C-x 2
>     C-x 2
>     M-x compile RET C-a C-k true RET
>
> "[Compiling]" correctly disappears from the current window and the
> compilation window, but it lingers on the mode-line of the third window.

Was this the case before, too, when the "Compiling" lighter was
displayed from minor-mode-alist, or is that somehow updated...
differently? 

> The attached patch trivially fixes the issue; I do not know whether it's
> appropriate, or maybe too heavyweight.
>
> WDYT?

-    (force-mode-line-update)
+    (force-mode-line-update t)

From the doc string, that sounds like the right thing to do -- I mean,
the lighter is displayed in all mode lines, so I guess you have to do it
that way?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

On July 25, 2019 12:42:27 PM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> 
> > The recent changes on the compilation-in-progress indicator[1] made
> me
> > realize that the indicator lingers in the mode-lines of some
> windows.
> > To reproduce from emacs -Q:
> >
> >     C-x 2
> >     C-x 2
> >     M-x compile RET C-a C-k true RET
> >
> > "[Compiling]" correctly disappears from the current window and the
> > compilation window, but it lingers on the mode-line of the third
> window.
> 
> Was this the case before, too, when the "Compiling" lighter was
> displayed from minor-mode-alist, or is that somehow updated...
> differently? 
> 
> > The attached patch trivially fixes the issue; I do not know whether
> it's
> > appropriate, or maybe too heavyweight.
> >
> > WDYT?
> 
> -    (force-mode-line-update)
> +    (force-mode-line-update t)
> 
> >From the doc string, that sounds like the right thing to do -- I
> mean,
> the lighter is displayed in all mode lines, so I guess you have to do
> it
> that way?

This seems to be a regression since Emacs 25, as it works for me upto and including Emacs 24.5.  So I think it would be nice to bisect to see which change caused this, before we decide how to fix it.

Thanks 

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

[Kévin Le Gouguec]

On Thu, Jul 25, 2019 at 12:34 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> This seems to be a regression since Emacs 25, as it works for me upto and including Emacs 24.5.  So I think it would be nice to bisect to see which change caused this, before we decide how to fix it.
>
> Thanks

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

I can't take an in-depth look at this commit right now (may do in a
few hours); I am sending this in case the issue (and hopefully, the
ideal fix) jumps out to you.

Thanks for identifying that this is actually a regression!

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

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Thu, 25 Jul 2019 15:37:37 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 36803@debbugs.gnu.org
> 
> > This seems to be a regression since Emacs 25, as it works for me upto and including Emacs 24.5.  So I think it would be nice to bisect to see which change caused this, before we decide how to fix it.
> >
> > Thanks
> 
> 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.

> I can't take an in-depth look at this commit right now (may do in a
> few hours); I am sending this in case the issue (and hopefully, the
> ideal fix) jumps out to you.

The very few first lines of the change are those which caused this,
the rest are just comment clarifications.

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

[Eli Zaretskii]

> Date: Thu, 25 Jul 2019 17:59:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 36803@debbugs.gnu.org, larsi@gnus.org
> 
> > 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.  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).

So I think we should restore the old code, i.e. revert this part of
the above-mentioned commit:

  --- a/src/process.c
  +++ b/src/process.c
  @@ -6694,10 +6694,12 @@ status_notify (struct Lisp_Process *deleting_process,
	    p->update_tick = p->tick;
	    /* Now output the message suitably.  */
	    exec_sentinel (proc, msg);
  +         if (BUFFERP (p->buffer))
  +           /* In case it uses %s in mode-line-format.  */
  +           bset_update_mode_line (XBUFFER (p->buffer));
	  }
       } /* end for */

  -  update_mode_lines = 24;  /* In case buffers use %s in mode-line-format.  */
     return got_some_output;
   }

Am I missing something?

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

[Stefan Monnier]

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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kevin.legouguec@gmail.com,  36803@debbugs.gnu.org,  larsi@gnus.org
> Date: Fri, 26 Jul 2019 09:59:39 -0400
> 
> > 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.

So you are saying that there's a redisplay bug, whereby some windows
that display a buffer don't have their mode line updated in the recipe
of this bug report?

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

force-mode-line-update with a non-nil argument affects all the
windows, even those which don't show the process status.  So why are
you saying it's TRT in this case?  Or are you talking about some other
issue?

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

[Stefan Monnier]

>> > 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.
>
> So you are saying that there's a redisplay bug, whereby some windows
> that display a buffer don't have their mode line updated in the recipe
> of this bug report?

In the recipe of this bug, we have a process in the compilation buffer
and the status of this process is reflected in the mode line of
*all* windows (via the compilation-in-progress variable).

The "process status" I'm referring to above is another kind of "process
status" in the mode-line: that of `mode-line-process` which is usually
buffer-local and only reflects the status of the process running in that
same buffer.

>> 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.
> force-mode-line-update with a non-nil argument affects all the
> windows, even those which don't show the process status.  So why are
> you saying it's TRT in this case?

Because the status of the compilation process *is* by default reflected
in the mode line of all windows (I disable this in my own config
because I don't like it).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 36803@debbugs.gnu.org,  larsi@gnus.org,  kevin.legouguec@gmail.com
> Date: Fri, 26 Jul 2019 12:23:26 -0400
> 
> > So you are saying that there's a redisplay bug, whereby some windows
> > that display a buffer don't have their mode line updated in the recipe
> > of this bug report?
> 
> In the recipe of this bug, we have a process in the compilation buffer
> and the status of this process is reflected in the mode line of
> *all* windows (via the compilation-in-progress variable).
> 
> The "process status" I'm referring to above is another kind of "process
> status" in the mode-line: that of `mode-line-process` which is usually
> buffer-local and only reflects the status of the process running in that
> same buffer.

But the recipe uses "C-x 2" several times, so all the windows display
the same buffer.  And yet one of them has its mode line not updated
after the process exist.

> >> 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.
> > force-mode-line-update with a non-nil argument affects all the
> > windows, even those which don't show the process status.  So why are
> > you saying it's TRT in this case?
> 
> Because the status of the compilation process *is* by default reflected
> in the mode line of all windows

Then we should update all mode lines when the status changes, and we
should not require any Lisp to force that update.

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

[Stefan Monnier]

>> The "process status" I'm referring to above is another kind of "process
>> status" in the mode-line: that of `mode-line-process` which is usually
>> buffer-local and only reflects the status of the process running in that
>> same buffer.
>
> But the recipe uses "C-x 2" several times, so all the windows display
> the same buffer.  And yet one of them has its mode line not updated
> after the process exist.

Right: there are 2 windows displaying the original buffer, plus a third
one displaying the compilation buffer.  The C code for process sentinels
makes sure that the mode-line of the window showing the compilation
buffer get updated (for the benefit of mode-line-process, presumably),
but none of the others.
As it so happens, one of the others also gets updated because it's the
currently selected_window.

> Then we should update all mode lines when the status changes, and we
> should not require any Lisp to force that update.

I don't see why we should do that every time a process sentinel is run,
while it's only needed for the sentinel of the compilation processes.

Especially since it only saves us one of the (force-mode-line-update t)
in my patch (the one that's in the process sentinel) but not the other
(the one that's in the code that launches the process).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 36803@debbugs.gnu.org,  larsi@gnus.org,  kevin.legouguec@gmail.com
> Date: Fri, 26 Jul 2019 14:53:43 -0400
> 
> >> The "process status" I'm referring to above is another kind of "process
> >> status" in the mode-line: that of `mode-line-process` which is usually
> >> buffer-local and only reflects the status of the process running in that
> >> same buffer.
> >
> > But the recipe uses "C-x 2" several times, so all the windows display
> > the same buffer.  And yet one of them has its mode line not updated
> > after the process exist.
> 
> Right: there are 2 windows displaying the original buffer, plus a third
> one displaying the compilation buffer.  The C code for process sentinels
> makes sure that the mode-line of the window showing the compilation
> buffer get updated (for the benefit of mode-line-process, presumably),
> but none of the others.
> As it so happens, one of the others also gets updated because it's the
> currently selected_window.

That's not what happens.  What happens is that one of the windows
still shows "Compiling" after the process exits.  That's what this bug
report is about.

If you are saying that that buffer's mode line wasn't supposed to show
the process status in the first place, then that's the bug we should
solve.  But right now the mode line of *scratch* does show "Compiling"
in all of its windows, so there's a global setting that is updated
when the process starts and ends, and that change isn't triggering the
update of mode lines in all the windows showing *scratch*.  I still
don't understand how you explain that inconsistency.

> > Then we should update all mode lines when the status changes, and we
> > should not require any Lisp to force that update.
> 
> I don't see why we should do that every time a process sentinel is run,
> while it's only needed for the sentinel of the compilation processes.
> 
> Especially since it only saves us one of the (force-mode-line-update t)
> in my patch (the one that's in the process sentinel) but not the other
> (the one that's in the code that launches the process).

If the call to force-mode-line-update is the solution you suggest,
then I think it is not a good solution.  We cannot rely in a call to
force-mode-line-update, because there's the default sentinel, and
because it's unreasonable to request each sentinel written in Lisp to
make that call.  If every sentinel must do that, then the core should
do that for them.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If the call to force-mode-line-update is the solution you suggest,
> then I think it is not a good solution.  We cannot rely in a call to
> force-mode-line-update, because there's the default sentinel, and
> because it's unreasonable to request each sentinel written in Lisp to
> make that call.  If every sentinel must do that, then the core should
> do that for them.

Well, when I was looking at where to move the "Compiling"
sort-of-lighter (from out of minor-mode-alist where it didn't belong), I
was looking for other modes that display things in mode lines in all
buffers -- and there doesn't seem to be many.

So while I agree that it seems more logical that this "should just
work", I think the problem is very limited in practice, and having
compile.el (as one of the very few packages that does this) call
force-mode-line-update wouldn't be an outrage.

(Another issue is whether compile.el should do this, and I kinda
think...  perhaps not?)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

>> Right: there are 2 windows displaying the original buffer, plus a third
>> one displaying the compilation buffer.  The C code for process sentinels
>> makes sure that the mode-line of the window showing the compilation
>> buffer get updated (for the benefit of mode-line-process, presumably),
>> but none of the others.
>> As it so happens, one of the others also gets updated because it's the
>> currently selected_window.
>
> That's not what happens.  What happens is that one of the windows
> still shows "Compiling" after the process exits.

AFAIK this is indeed just what I describe in the previous paragraph
(i.e. at the end of the compilation, when the sentinel is run, the
C part of the sentinel processing causes the refresh of the mode-line
of the window showing the compilation buffer, the redisplay itself will
on its own accord decide to refresh the selected window's mode-line,
but the third window's mode-line is not refreshed because noone tells
the C code that all mode-lines indicated the status of this specific
process).

> If you are saying that that buffer's mode line wasn't supposed to show
> the process status in the first place, then that's the bug we should
> solve.

No, I only indicated as a side-comment that this default of showing the
status of the compilation process in all mode lines is a behavior I dislike.

> But right now the mode line of *scratch* does show "Compiling"
> in all of its windows, so there's a global setting that is updated
> when the process starts and ends,

Indeed.

> and that change isn't triggering the update of mode lines in all the
> windows showing *scratch*.  I still don't understand how you explain
> that inconsistency.

Very simple: the change in the mode-line is caused by a change to the
`compilation-in-progress` global variable.  Yet, the mode-line
infrastructure is not setup to track dependencies on variables; instead
it's traditionally the responsability of the code which sets this
variable to explicitly call force-mode-line-update (as is done, for
example in all minor-modes (from within `define-minor-mode`)).

> If the call to force-mode-line-update is the solution you suggest,
> then I think it is not a good solution.  We cannot rely in a call to
> force-mode-line-update, because there's the default sentinel, and

The default sentinel does not modify `compilation-in-progress` (nor any
other global variable for that matter), so there's never any need to
update all the mode-lines at the end of a process using the default sentinel.

> because it's unreasonable to request each sentinel written in Lisp to
> make that call.  If every sentinel must do that, then the core should
> do that for them.

Not all sentinels must so that.  Only those which set global variables
whose content affects the mode-line of "all" windows (not necessarily
all, tho, but at least more than just the mode lines of the current
buffer).

There might be a few beside compile.el's sentinel, but they are the
exception rather than the rule.


        Stefan

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

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (Another issue is whether compile.el should [display things in mode
> lines in all buffers], and I kinda think...  perhaps not?)

Mmm, I guess the rationale is that since

1. the user may bury the compilation buffer if the process takes a long
   time,

2. the user may miss the "Compilation finished" message (e.g. it can be
   hidden by any movement command that triggers a "Mark set" message),

The only reliable way to inform the user that the compilation process is
still running is to spray all mode-lines with an indicator…

(I have notifications-notify in compilation-finish-functions, so as far
as I am concerned, I could live without this indicator; for a stock
Emacs configuration though, I can't think of another signaling method…)

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  36803@debbugs.gnu.org,
>   kevin.legouguec@gmail.com
> Date: Fri, 26 Jul 2019 21:35:14 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the call to force-mode-line-update is the solution you suggest,
> > then I think it is not a good solution.  We cannot rely in a call to
> > force-mode-line-update, because there's the default sentinel, and
> > because it's unreasonable to request each sentinel written in Lisp to
> > make that call.  If every sentinel must do that, then the core should
> > do that for them.
> 
> Well, when I was looking at where to move the "Compiling"
> sort-of-lighter (from out of minor-mode-alist where it didn't belong), I
> was looking for other modes that display things in mode lines in all
> buffers -- and there doesn't seem to be many.

I'm not talking about just any change to the mode line.  I'm talking
specifically about the process status indicator there.  The process
status change is detected by the C code, so that's where we should
make sure the mode line gets updated regarding the process status.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 36803@debbugs.gnu.org,  larsi@gnus.org,  kevin.legouguec@gmail.com
> Date: Fri, 26 Jul 2019 17:10:40 -0400
> 
> >> Right: there are 2 windows displaying the original buffer, plus a third
> >> one displaying the compilation buffer.  The C code for process sentinels
> >> makes sure that the mode-line of the window showing the compilation
> >> buffer get updated (for the benefit of mode-line-process, presumably),
> >> but none of the others.
> >> As it so happens, one of the others also gets updated because it's the
> >> currently selected_window.
> >
> > That's not what happens.  What happens is that one of the windows
> > still shows "Compiling" after the process exits.
> 
> AFAIK this is indeed just what I describe in the previous paragraph
> (i.e. at the end of the compilation, when the sentinel is run, the
> C part of the sentinel processing causes the refresh of the mode-line
> of the window showing the compilation buffer, the redisplay itself will
> on its own accord decide to refresh the selected window's mode-line,
> but the third window's mode-line is not refreshed because noone tells
> the C code that all mode-lines indicated the status of this specific
> process).

Yes.  And if you add to the recipe yet another, unrelated buffer
displayed in the 4th window, then its mode line will also show
"Compiling" if that buffer is not the current buffer when "M-x
compile" is invoked.

> > But right now the mode line of *scratch* does show "Compiling"
> > in all of its windows, so there's a global setting that is updated
> > when the process starts and ends,
> 
> Indeed.
> 
> > and that change isn't triggering the update of mode lines in all the
> > windows showing *scratch*.  I still don't understand how you explain
> > that inconsistency.
> 
> Very simple: the change in the mode-line is caused by a change to the
> `compilation-in-progress` global variable.  Yet, the mode-line
> infrastructure is not setup to track dependencies on variables; instead
> it's traditionally the responsability of the code which sets this
> variable to explicitly call force-mode-line-update (as is done, for
> example in all minor-modes (from within `define-minor-mode`)).

The variable compilation-in-progress is specific to compile.el.
However, the problem its use exposes is more general, and the general
problem cannot IMO be reasonably put under the responsibility of the
code which could cause it (and I don't really agree with the
"traditional" part above).  More about this below.

> > If the call to force-mode-line-update is the solution you suggest,
> > then I think it is not a good solution.  We cannot rely in a call to
> > force-mode-line-update, because there's the default sentinel, and
> 
> The default sentinel does not modify `compilation-in-progress` (nor any
> other global variable for that matter), so there's never any need to
> update all the mode-lines at the end of a process using the default sentinel.
> 
> > because it's unreasonable to request each sentinel written in Lisp to
> > make that call.  If every sentinel must do that, then the core should
> > do that for them.
> 
> Not all sentinels must so that.  Only those which set global variables
> whose content affects the mode-line of "all" windows (not necessarily
> all, tho, but at least more than just the mode lines of the current
> buffer).

And that brings me right back to the beginning.  In response to my
original question, you said:

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

This is true only if the process status is modified via
mode-line-process, which is a buffer-local variable.  If a Lisp
program modifies the mode line directly, the result will be global.
That's what compile.el does via compilation-in-progress, but the most
basic operation is simply to add %s to mode-line-format (or to
header-line-format or even to frame-title-format).  When a Lisp
program or the user does that, I see no way of keeping that indicator
up to date except trigger mode-line updates in all windows in
status_notify.  Any other method will be simply unreliable.

Am I missing something?

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

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Mmm, I guess the rationale is that since
>
> 1. the user may bury the compilation buffer if the process takes a long
>    time,
>
> 2. the user may miss the "Compilation finished" message (e.g. it can be
>    hidden by any movement command that triggers a "Mark set" message),
>
> The only reliable way to inform the user that the compilation process is
> still running is to spray all mode-lines with an indicator…

I guess...  but it's not like Emacs doesn't have a lot of things that
run asynchronously.  Very few of them alter the mode-line in all the
modes.

erc does, and that's very useful (it notifies you that somebody's sent
you a message, for instance), but the compilation thing just doesn't
seem that...  urgent?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

> Yes.  And if you add to the recipe yet another, unrelated buffer
> displayed in the 4th window, then its mode line will also show
> "Compiling" if that buffer is not the current buffer when "M-x
> compile" is invoked.

Yes, with 100 windows, 98 of them will stay stale.

> And that brings me right back to the beginning.  In response to my
> original question, you said:
>
>> 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.
>
> This is true only if the process status is modified via
> mode-line-process, which is a buffer-local variable.  If a Lisp
> program modifies the mode line directly, the result will be global.
> That's what compile.el does via compilation-in-progress, but the most
> basic operation is simply to add %s to mode-line-format (or to
> header-line-format or even to frame-title-format).

That's not a problem: %s only shows the status *of the process in the
current buffer*: the status of a process in buffer A is never
reflected in the %s part of the mode-line of other buffers, which is why
the sentinel code only causes a mode-line update for the process's buffer.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 36803@debbugs.gnu.org,  larsi@gnus.org,  kevin.legouguec@gmail.com
> Date: Sat, 27 Jul 2019 08:46:35 -0400
> 
> >> 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.
> >
> > This is true only if the process status is modified via
> > mode-line-process, which is a buffer-local variable.  If a Lisp
> > program modifies the mode line directly, the result will be global.
> > That's what compile.el does via compilation-in-progress, but the most
> > basic operation is simply to add %s to mode-line-format (or to
> > header-line-format or even to frame-title-format).
> 
> That's not a problem: %s only shows the status *of the process in the
> current buffer*: the status of a process in buffer A is never
> reflected in the %s part of the mode-line of other buffers, which is why
> the sentinel code only causes a mode-line update for the process's buffer.

If there's no way for a Lisp program to inject a global process-status
element into the mode line, then I guess your patch is TRT, indeed.
Thanks.

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

[Stefan Monnier]

> If there's no way for a Lisp program to inject a global process-status
> element into the mode line, then I guess your patch is TRT, indeed.

Thanks, installed,


        Stefan

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

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> The only reliable way to inform the user that the compilation process is
>> still running is to spray all mode-lines with an indicator…
>
> I guess...  but it's not like Emacs doesn't have a lot of things that
> run asynchronously.  Very few of them alter the mode-line in all the
> modes.
>
> erc does, and that's very useful (it notifies you that somebody's sent
> you a message, for instance), but the compilation thing just doesn't
> seem that...  urgent?

Mmm…  I was about to say that since I often wait on compilation
processes to validate something before committing changes or sending an
email, I'd rather be notified immediately, but updating the mode-line to
remove the indicator is actually not that informative.  I still need to
bring up the compilation buffer to know whether the process succeeded…

So maybe cluttering every mode-line does not actually help that much,
indeed.

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

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Thanks, installed,
>
>
>         Stefan

Thank you all for getting to the bottom of this issue!  AFAICT the
committed patch works fine.