From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36803: 27.0.50; Update mode-line of every window when compilation ends Date: Fri, 26 Jul 2019 22:21:37 +0300 Message-ID: <83ef2cmwji.fsf@gnu.org> References: <877e87i0vw.fsf@gmail.com> <87imrqcuws.fsf@mouse.gnus.org> <83ef2enosr.fsf@gnu.org> <83r26dmcx3.fsf@gnu.org> <83imron88m.fsf@gnu.org> <83h878mzjc.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265164"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36803@debbugs.gnu.org, larsi@gnus.org, kevin.legouguec@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 26 21:22:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hr5n8-0016pI-46 for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Jul 2019 21:22:10 +0200 Original-Received: from localhost ([::1]:43080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hr5n6-0007ot-Ij for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Jul 2019 15:22:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49657) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hr5n2-0007hP-Kj for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 15:22:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hr5n1-0007N2-FF for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 15:22:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34563) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hr5n1-0007Ml-BS for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 15:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hr5n0-0003R5-4J for bug-gnu-emacs@gnu.org; Fri, 26 Jul 2019 15:22:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Jul 2019 19:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36803 X-GNU-PR-Package: emacs Original-Received: via spool by 36803-submit@debbugs.gnu.org id=B36803.156416891313190 (code B ref 36803); Fri, 26 Jul 2019 19:22:02 +0000 Original-Received: (at 36803) by debbugs.gnu.org; 26 Jul 2019 19:21:53 +0000 Original-Received: from localhost ([127.0.0.1]:43384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hr5mq-0003Qg-Mf for submit@debbugs.gnu.org; Fri, 26 Jul 2019 15:21:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36937) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hr5mo-0003QU-Vz for 36803@debbugs.gnu.org; Fri, 26 Jul 2019 15:21:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hr5mi-0006hl-Sl; Fri, 26 Jul 2019 15:21:44 -0400 Original-Received: from [176.228.60.248] (port=4995 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hr5mg-00083S-4t; Fri, 26 Jul 2019 15:21:42 -0400 In-reply-to: (message from Stefan Monnier on Fri, 26 Jul 2019 14:53:43 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163813 Archived-At: > From: Stefan Monnier > 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.