unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
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 22:21:37 +0300	[thread overview]
Message-ID: <83ef2cmwji.fsf@gnu.org> (raw)
In-Reply-To: <jwvimroocoa.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 26 Jul 2019 14:53:43 -0400)

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





  reply	other threads:[~2019-07-26 19:21 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
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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83ef2cmwji.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=36803@debbugs.gnu.org \
    --cc=kevin.legouguec@gmail.com \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).