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.