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: Sat, 27 Jul 2019 10:46:38 +0300 Message-ID: <83a7czncm9.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> <83ef2cmwji.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265418"; 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 Sat Jul 27 09:47:09 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 1hrHQ4-0016q0-P2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jul 2019 09:47:08 +0200 Original-Received: from localhost ([::1]:44482 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrHQ3-0004Zo-Bm for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Jul 2019 03:47:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45329) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrHQ0-0004ZW-De for bug-gnu-emacs@gnu.org; Sat, 27 Jul 2019 03:47:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hrHPy-0008H3-Ql for bug-gnu-emacs@gnu.org; Sat, 27 Jul 2019 03:47:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34746) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hrHPy-0008Gw-J2 for bug-gnu-emacs@gnu.org; Sat, 27 Jul 2019 03:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hrHPy-0002SF-FA for bug-gnu-emacs@gnu.org; Sat, 27 Jul 2019 03:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Jul 2019 07:47: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.15642136129419 (code B ref 36803); Sat, 27 Jul 2019 07:47:02 +0000 Original-Received: (at 36803) by debbugs.gnu.org; 27 Jul 2019 07:46:52 +0000 Original-Received: from localhost ([127.0.0.1]:43567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrHPn-0002Rq-P2 for submit@debbugs.gnu.org; Sat, 27 Jul 2019 03:46:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrHPm-0002Re-5M for 36803@debbugs.gnu.org; Sat, 27 Jul 2019 03:46:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hrHPf-00087r-VK; Sat, 27 Jul 2019 03:46:44 -0400 Original-Received: from [176.228.60.248] (port=2499 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hrHPf-0002GN-E7; Sat, 27 Jul 2019 03:46:43 -0400 In-reply-to: (message from Stefan Monnier on Fri, 26 Jul 2019 17:10:40 -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:163825 Archived-At: > From: Stefan Monnier > 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?