GNU bug report logs - #13225
24.3.50; Non-selected window has not mode-line-inactive face

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13225 in the body.
You can then email your comments to 13225 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 09:12:15 +0100

With emacs -Q do C-x 5 2.  The mode lines of both windows appear in
`mode-line' face, regardless of which window is selected.

This contradicts the Elisp manual which says:

      The selected window's mode line is usually displayed in a different
   color using the face `mode-line'.  Other windows' mode lines appear in
   the face `mode-line-inactive' instead.


In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-19 on MACHNO
Bzr revision: 111265 eliz <at> gnu.org-20121218190556-x9wmq083vwecgu0f
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt'

martin

Message #8 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 18:07:18 +0200

> Date: Wed, 19 Dec 2012 09:12:15 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> 
> With emacs -Q do C-x 5 2.  The mode lines of both windows appear in
> `mode-line' face, regardless of which window is selected.
> 
> This contradicts the Elisp manual which says:
> 
>        The selected window's mode line is usually displayed in a different
>     color using the face `mode-line'.  Other windows' mode lines appear in
>     the face `mode-line-inactive' instead.

We are shooting ourselves in the foot.  At some point during
redisplay, it loops over all the frames and redisplays every window of
every visible frame.  Here's the beginning of that loop:

      FOR_EACH_FRAME (tail, frame)
	{
	  struct frame *f = XFRAME (frame);

	  /* We don't have to do anything for unselected terminal
	     frames.  */
	  if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))
	      && !EQ (FRAME_TTY (f)->top_frame, frame))
	    continue;

	  if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf)
	    {
	      /* Select the frame, for the sake of frame-local variables.  */
	      ensure_selected_frame (frame);

	      /* Mark all the scroll bars to be removed; we'll redeem
		 the ones we want when we redisplay their windows.  */
	      if (FRAME_TERMINAL (f)->condemn_scroll_bars_hook)
		FRAME_TERMINAL (f)->condemn_scroll_bars_hook (f);

	      if (FRAME_VISIBLE_P (f) && !FRAME_OBSCURED_P (f))
		redisplay_windows (FRAME_ROOT_WINDOW (f));

Where we now call ensure_selected_frame, originally there was a call
to select_frame_for_redisplay, which arranged for all the frame-local
variables to appear in C variables.  But now it does this in addition:

  selected_frame = frame;
  /* If redisplay causes scrolling, it sets point in the window, so we need to
     be careful with the selected-window's point handling.  */
  select_window_1 (XFRAME (frame)->selected_window, 0);

This selects the frame, and _also_ makes that frame's selected window
be the global selected_window.  Therefore, when display_mode_lines
comes to select a proper face for the mode line, it always finds the
frame's selected window in selected_window, and thus always uses the
face for selected windows.

I can fix this with the kludge shown below, but do we care about yet
another global variable, in addition to selected_window?  If we don't
want this, then the only other way I see is to drag this window all
the way down to display_mode_lines through the calling sequences.
(That's assuming that only the mode-line display wants to know about
the _real_ selected_window.)

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-12-17 19:17:06 +0000
+++ src/xdisp.c	2012-12-19 16:02:53 +0000
@@ -13006,6 +13006,8 @@ do { if (polling_stopped_here) start_pol
 /* Perhaps in the future avoid recentering windows if it
    is not necessary; currently that causes some problems.  */
 
+static struct window *sw_on_sf;
+
 static void
 redisplay_internal (void)
 {
@@ -13491,6 +13493,8 @@ redisplay_internal (void)
 
 	  if (FRAME_WINDOW_P (f) || FRAME_TERMCAP_P (f) || f == sf)
 	    {
+	      sw_on_sf = sw;
+
 	      /* Select the frame, for the sake of frame-local variables.  */
 	      ensure_selected_frame (frame);
 
@@ -20371,7 +20375,7 @@ display_mode_lines (struct window *w)
 
   if (WINDOW_WANTS_MODELINE_P (w))
     {
-      struct window *sel_w = XWINDOW (old_selected_window);
+      struct window *sel_w = sw_on_sf;
 
       /* Select mode line face based on the real selected window.  */
       display_mode_line (w, CURRENT_MODE_LINE_FACE_ID_3 (sel_w, sel_w, w),

Message #11 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 13:30:54 -0500

>   selected_frame = frame;
>   /* If redisplay causes scrolling, it sets point in the window, so we need to
>      be careful with the selected-window's point handling.  */
>   select_window_1 (XFRAME (frame)->selected_window, 0);

> This selects the frame, and _also_ makes that frame's selected window
> be the global selected_window.  Therefore, when display_mode_lines
> comes to select a proper face for the mode line, it always finds the
> frame's selected window in selected_window, and thus always uses the
> face for selected windows.

Ah, yes, that makes sense.
Of course, when we drop frame-local variables this problem
will disappear.

Maybe we should live with the "selected_frame->selected_window !=
selected_window" problem until we get rid of frame-local vars.


        Stefan

Message #14 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 13225 <at> debbugs.gnu.org
Subject: RE: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 11:16:29 -0800

> Of course, when we drop frame-local variables this problem
> will disappear.
> 
> Maybe we should live with the "selected_frame->selected_window !=
> selected_window" problem until we get rid of frame-local vars.

And just why have you decided to drop frame-local vars?

I don't use them - just wondering.  Who have they hurt?
Why were they created?  Is that purpose no longer valid?
Does no one use them for anything?

Message #17 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 'Alp Aker' <alptekin.aker <at> gmail.com>, 13225 <at> debbugs.gnu.org
Subject: RE: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 11:28:12 -0800

> > Of course, when we drop frame-local variables this problem
> > will disappear.
> > 
> > Maybe we should live with the "selected_frame->selected_window !=
> > selected_window" problem until we get rid of frame-local vars.
> 
> And just why have you decided to drop frame-local vars?
> 
> I don't use them - just wondering.  Who have they hurt?
> Why were they created?  Is that purpose no longer valid?
> Does no one use them for anything?

BTW, you might want to have a look at Alp Aker's library `frame-bufs.el' (ccing
him):

overview: http://www.emacswiki.org/emacs/FrameBufs
code:     http://www.emacswiki.org/emacs/download/frame-bufs.el

From the overview:

Frame-bufs is intended as a convenience for those who like to organize their
workflow in Emacs by using specific frames for different projects.  It extends
Emacs's buffer menu so that it understands a distinction between those buffers
that are associated with a given frame and those that are not.  The buffer menu
can be toggled between a list of all buffers and a list of only those buffers
associated with the selected frame.  The criteria governing which buffers are
associated with a frame can be customized through various options.  In addition,
buffers can be manually added to and removed from the list of buffers associated
with a frame.  The package interacts properly with other-buffer and respects
changes in buffer ordering made by bury-buffer.

Message #20 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Alp Aker' <alptekin.aker <at> gmail.com>, 'Eli Zaretskii' <eliz <at> gnu.org>,
	13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 15:07:00 -0500

> code:     http://www.emacswiki.org/emacs/download/frame-bufs.el

No "frame-local" in sight, sorry.
But thanks for playing,


        Stefan

Message #23 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Alp Aker' <alptekin.aker <at> gmail.com>, 'Eli Zaretskii' <eliz <at> gnu.org>,
	13225 <at> debbugs.gnu.org
Subject: RE: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 12:56:00 -0800

> > code: http://www.emacswiki.org/emacs/download/frame-bufs.el
> 
> No "frame-local" in sight, sorry.
> But thanks for playing,

My bad.  Sorry for the distraction.  I guess I was confusing a frame's buffer
list with frame-local variables.

Message #26 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 23:36:40 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: martin rudalics <rudalics <at> gmx.at>,  13225 <at> debbugs.gnu.org
> Date: Wed, 19 Dec 2012 13:30:54 -0500
> 
> Of course, when we drop frame-local variables this problem
> will disappear.

You mean, there will be no longer a need to call ensure_selected_frame?

> Maybe we should live with the "selected_frame->selected_window !=
> selected_window" problem until we get rid of frame-local vars.

What does this mean in practice? revert your latest changes and delete
the assertions that triggered those changes?

Message #29 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Alp Aker' <alptekin.aker <at> gmail.com>, 'Eli Zaretskii' <eliz <at> gnu.org>,
	13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 19:52:11 -0500

>> > code: http://www.emacswiki.org/emacs/download/frame-bufs.el
>> No "frame-local" in sight, sorry.
>> But thanks for playing,
> My bad.  Sorry for the distraction.  I guess I was confusing a frame's buffer
> list with frame-local variables.

FWIW the only use I can still find of frame-local vars is in ECB.


        Stefan

Message #32 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Wed, 19 Dec 2012 21:08:08 -0500

>> Of course, when we drop frame-local variables this problem
>> will disappear.
> You mean, there will be no longer a need to call ensure_selected_frame?

Yup.

>> Maybe we should live with the "selected_frame->selected_window !=
>> selected_window" problem until we get rid of frame-local vars.
> What does this mean in practice? revert your latest changes and delete
> the assertions that triggered those changes?

Yes.


        Stefan

Message #35 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Thu, 20 Dec 2012 10:59:00 +0100

> I can fix this with the kludge shown below, but do we care about yet
> another global variable, in addition to selected_window?  If we don't
> want this, then the only other way I see is to drag this window all
> the way down to display_mode_lines through the calling sequences.
> (That's assuming that only the mode-line display wants to know about
> the _real_ selected_window.)

There might still be glitches with the region as Angelo mentioned in the
previous thread.  But I am surprised that currently the cursor is drawn
correctly, that is, a hollow box is drawn on the non-selected frame's
window.  How is that managed without a kludge similar to the one you
describe here?

In any case, I think that some crashes Drew reported could be due to the
inconsistency Stefan tries to resolve here.  So it might be better to go
on with the changes and look first whether these crashes disappear.  You
can always revert them later after we gained some experience.

martin

Message #38 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Thu, 20 Dec 2012 10:59:07 +0100

> Of course, when we drop frame-local variables this problem
> will disappear.
>
> Maybe we should live with the "selected_frame->selected_window !=
> selected_window" problem until we get rid of frame-local vars.

I completely fail to understand how frame-local variables are related to
the problem at hand :-(

martin

Message #41 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Thu, 20 Dec 2012 09:03:01 -0500

>> Of course, when we drop frame-local variables this problem
>> will disappear.
>> Maybe we should live with the "selected_frame->selected_window !=
>> selected_window" problem until we get rid of frame-local vars.
> I completely fail to understand how frame-local variables are related to
> the problem at hand :-(

Here's the connection: in order for the redisplay code to use the proper
value of (frame-local) variables, it needs to `select-frame' on the
frame being redisplayed.  Since selected-frame and selected-window
should be kept in sync, this means changing the selected-window as well,
hence the bug where each frame's selected_window is drawn as if it were
the global selected-window (the cursor seems to be unaffected, probably
because drawing the cursor is handled specially, so I suspect this
cursor code does not obey frame-local variables).

Actually, now that I think about it, maybe the right fix is to remove
this ensure_selected_frame.  It would be one more step towards removing
frame-local variables (just like we already disallowed variables that
are both buffer-local and frame-local), but still without removing them
altogether.  After all, I don't think that the existing uses of
frame-local vars affect the redisplay.

I've just made this change.


        Stefan

Message #44 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rudalics <at> gmx.at, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Thu, 20 Dec 2012 18:28:08 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  13225 <at> debbugs.gnu.org
> Date: Thu, 20 Dec 2012 09:03:01 -0500
> 
> the cursor seems to be unaffected, probably because drawing the
> cursor is handled specially, so I suspect this cursor code does not
> obey frame-local variables.

The cursor is unaffected, because we use a different test there, see
get_window_cursor_type.

> Actually, now that I think about it, maybe the right fix is to remove
> this ensure_selected_frame.  It would be one more step towards removing
> frame-local variables (just like we already disallowed variables that
> are both buffer-local and frame-local), but still without removing them
> altogether.  After all, I don't think that the existing uses of
> frame-local vars affect the redisplay.
> 
> I've just made this change.

Thanks.

Message #47 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Thu, 20 Dec 2012 19:09:06 +0200

> Date: Thu, 20 Dec 2012 10:59:00 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 13225 <at> debbugs.gnu.org
> 
>  > I can fix this with the kludge shown below, but do we care about yet
>  > another global variable, in addition to selected_window?  If we don't
>  > want this, then the only other way I see is to drag this window all
>  > the way down to display_mode_lines through the calling sequences.
>  > (That's assuming that only the mode-line display wants to know about
>  > the _real_ selected_window.)
> 
> There might still be glitches with the region as Angelo mentioned in the
> previous thread.

Could someone please post a complete precise recipe, starting from
"emacs -Q"?  I don't think I understand what glitches are we talking
about.

> But I am surprised that currently the cursor is drawn correctly,
> that is, a hollow box is drawn on the non-selected frame's window.
> How is that managed without a kludge similar to the one you describe
> here?

I just explained that in another message here.

Message #50 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Thu, 20 Dec 2012 18:24:54 +0100

> The cursor is unaffected, because we use a different test there, see
> get_window_cursor_type.

Does this mean we could have used something like

  if (w = XWINDOW (f->selected_window)
      && f = FRAME_X_DISPLAY_INFO (f)->x_highlight_frame)

for checking whether the mode line should indicate that w is the
selected window?

martin

Message #53 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Thu, 20 Dec 2012 18:24:58 +0100

>> There might still be glitches with the region as Angelo mentioned in the
>> previous thread.
>
> Could someone please post a complete precise recipe, starting from
> "emacs -Q"?  I don't think I understand what glitches are we talking
> about.

I couldn't reproduce that either.  But I suppose that the problem is no
more reproducible anyway with Stefan's last change.

martin

Message #56 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Thu, 20 Dec 2012 18:25:03 +0100

> Here's the connection: in order for the redisplay code to use the proper
> value of (frame-local) variables, it needs to `select-frame' on the
> frame being redisplayed.

Ahh, sure.

> Actually, now that I think about it, maybe the right fix is to remove
> this ensure_selected_frame.  It would be one more step towards removing
> frame-local variables (just like we already disallowed variables that
> are both buffer-local and frame-local), but still without removing them
> altogether.  After all, I don't think that the existing uses of
> frame-local vars affect the redisplay.
>
> I've just made this change.

So we can be sure that redisplay now nowhere changes the selected frame
or the selected window?

martin

Message #59 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Thu, 20 Dec 2012 19:37:08 +0200

> Date: Thu, 20 Dec 2012 18:24:54 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13225 <at> debbugs.gnu.org
> 
>  > The cursor is unaffected, because we use a different test there, see
>  > get_window_cursor_type.
> 
> Does this mean we could have used something like
> 
>    if (w = XWINDOW (f->selected_window)
>        && f = FRAME_X_DISPLAY_INFO (f)->x_highlight_frame)
> 
> for checking whether the mode line should indicate that w is the
> selected window?

Maybe, I'm not sure.  There's this note in the comments to
x_highlight_frame member:

  /* The frame which currently has the visual highlight, and should get
     keyboard input (other sorts of input have the frame encoded in the
     event).  It points to the X focus frame's selected window's
     frame.  It differs from x_focus_frame when we're using a global
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     minibuffer.  */
     ^^^^^^^^^^

How is (or should be) the mode line displayed when input goes to a
"global minibuffer"?

Message #62 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Thu, 20 Dec 2012 13:07:53 -0500

>> I've just made this change.
> So we can be sure that redisplay now nowhere changes the selected frame
> or the selected window?

No: it is still changed while computing the mode-line, but that's been
the case for a long time now (the recent change in this area is to not
only change selected_frame and selected_window but also
selected_frame->selected_window so that we preserve the invariant that
selected_windows = selected_frame->selected_window).


        Stefan

Message #65 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Fri, 21 Dec 2012 10:15:54 +0100

> There's this note in the comments to
> x_highlight_frame member:
>
>   /* The frame which currently has the visual highlight, and should get
>      keyboard input (other sorts of input have the frame encoded in the
>      event).  It points to the X focus frame's selected window's
>      frame.  It differs from x_focus_frame when we're using a global
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      minibuffer.  */
>      ^^^^^^^^^^
>
> How is (or should be) the mode line displayed when input goes to a
> "global minibuffer"?

My question was probably silly: We highlight the cursor as active when
the associated frame is currently visually highlighted by the window
manager.  And we highlight the mode line when the associated window is
the selected window, regardless of whether its frame is currently
visually highlighted by the window manager.  Is that interpretation
correct?  Then indeed we should not de-highlight a mode line when its
frame is not highlighted because we would lose some useful feedback.

martin

Message #68 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Fri, 21 Dec 2012 10:16:02 +0100

>> So we can be sure that redisplay now nowhere changes the selected frame
>> or the selected window?
>
> No: it is still changed while computing the mode-line,

... and this is good because otherwise Lisp code would have problems to
get the window whose mode line shall be displayed, I presume ...

> but that's been
> the case for a long time now (the recent change in this area is to not
> only change selected_frame and selected_window but also
> selected_frame->selected_window so that we preserve the invariant that
> selected_windows = selected_frame->selected_window).

... and while we compute the mode line we don't care whether
selected_frame->selected_window equals selected_window.  Wouldn't it be
more correct to handle this as in run_window_configuration_change_hook?

martin

Message #71 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Fri, 21 Dec 2012 11:35:18 +0200

> Date: Fri, 21 Dec 2012 10:15:54 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
> 
>  > There's this note in the comments to
>  > x_highlight_frame member:
>  >
>  >   /* The frame which currently has the visual highlight, and should get
>  >      keyboard input (other sorts of input have the frame encoded in the
>  >      event).  It points to the X focus frame's selected window's
>  >      frame.  It differs from x_focus_frame when we're using a global
>  >              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  >      minibuffer.  */
>  >      ^^^^^^^^^^
>  >
>  > How is (or should be) the mode line displayed when input goes to a
>  > "global minibuffer"?
> 
> My question was probably silly: We highlight the cursor as active when
> the associated frame is currently visually highlighted by the window
> manager.  And we highlight the mode line when the associated window is
> the selected window, regardless of whether its frame is currently
> visually highlighted by the window manager.  Is that interpretation
> correct?

I think so.  But I also think that the currently highlighted frame is
mostly identical to the selected frame, except when minbuffer-only
frames are in use.  And recall that the problems with mismatches
between the selected window and the selected frame, which started all
this quest for having them in sync, and introduced assertions whose
violations are being reported ever since, happen precisely in
configurations where the minbuffer is a separate frame.

> Then indeed we should not de-highlight a mode line when its frame is
> not highlighted because we would lose some useful feedback.

Maybe, but that could be a surprise to users, who are used to
different behavior.

Message #74 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Fri, 21 Dec 2012 15:24:39 +0100

>> Then indeed we should not de-highlight a mode line when its frame is
>> not highlighted because we would lose some useful feedback.
>
> Maybe, but that could be a surprise to users, who are used to
> different behavior.

Sorry, we probably miscommunicated.  What I described should have
reflected the status quo: When the minibuffer is active (regardless of
whether it's standalone, global, or on the only visible frame), that
fact is communicated by giving it the active cursor.  At the same time,
the mode line of the window that was selected before the minibuffer
became active is still highlighted as active.  Is that correct?

martin

Message #77 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Fri, 21 Dec 2012 16:43:21 +0200

> Date: Fri, 21 Dec 2012 15:24:39 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: monnier <at> iro.umontreal.ca, 13225 <at> debbugs.gnu.org
> 
> When the minibuffer is active (regardless of whether it's
> standalone, global, or on the only visible frame), that fact is
> communicated by giving it the active cursor.  At the same time, the
> mode line of the window that was selected before the minibuffer
> became active is still highlighted as active.  Is that correct?

Yes, of course.  Nothing else would make sense to me.

Message #80 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Sat, 22 Dec 2012 10:52:33 -0500

> ... and while we compute the mode line we don't care whether
> selected_frame-> selected_window equals selected_window.

What makes you think so?

> Wouldn't it be more correct to handle this as in
> run_window_configuration_change_hook?

I don't know how run_window_configuration_change_hook handles "this".


        Stefan

Message #83 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Sat, 22 Dec 2012 17:05:23 +0100

>> ... and while we compute the mode line we don't care whether
>> selected_frame-> selected_window equals selected_window.
>
> What makes you think so?

So we do?

>> Wouldn't it be more correct to handle this as in
>> run_window_configuration_change_hook?
>
> I don't know how run_window_configuration_change_hook handles "this".

Hmmm... that's your code so I can only provide my interpretation of it:
run_window_configuration_change_hook uses select_window_norecord (which
preserves the selected_frame->selected_window = selected_window property
we, according to your question above, do care about.  display_mode_lines
does only XSETWINDOW (selected_window, w) which does not preserve that
property IIUC.

martin

Message #86 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Sat, 22 Dec 2012 11:56:28 -0500

>>> ... and while we compute the mode line we don't care whether
>>> selected_frame-> selected_window equals selected_window.
>> What makes you think so?
> So we do?

I believe we always do, especially when (potentially) running Elisp
code, which can in turn run pretty much any code.

>>> Wouldn't it be more correct to handle this as in
>>> run_window_configuration_change_hook?
>> I don't know how run_window_configuration_change_hook handles "this".

> Hmmm... that's your code so I can only provide my interpretation of it:
> run_window_configuration_change_hook uses select_window_norecord (which
> preserves the selected_frame->selected_window = selected_window property
> we, according to your question above, do care about.  display_mode_lines
> does only XSETWINDOW (selected_window, w) which does not preserve that
> property IIUC.

Oh, that's what you mean.  Yes, maybe we could/should just use
select_window(_norecord) (which is not just the way
run_window_configuration_change_hook does it, but is more generally the
normal way to do it).  My recent change already brings display_mode_lines
closer to what select_window does.


        Stefan

Message #89 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Sat, 22 Dec 2012 18:42:04 +0100

> I believe we always do, especially when (potentially) running Elisp
> code, which can in turn run pretty much any code.

Who am I to object?  I thought the purpose of this was that a user can,
in her mode line code, call `frame-selected-window' to check whether the
currently selected window really is the selected window (at least in a
one-frame environment).  If we synchronize the frame's selected window
too, there's no way to get that any more.  Not that such a kludgy
behavior seems reasonable ...

> Oh, that's what you mean.  Yes, maybe we could/should just use
> select_window(_norecord) (which is not just the way
> run_window_configuration_change_hook does it,

If the function on the hook is local to the window's buffer, it does
precisely that.  Which is not entirely kosher because that function will
have no idea about the really selected window but we always have the
global hook for that.

> but is more generally the
> normal way to do it).  My recent change already brings display_mode_lines
> closer to what select_window does.

IIUC display_mode_lines contains the only Lisp running code where the
selected window does not necessarily equal the selected window of its
frame.  So it might be worth to fix this.

martin

Message #92 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Sun, 23 Dec 2012 08:41:00 -0500

>> I believe we always do, especially when (potentially) running Elisp
>> code, which can in turn run pretty much any code.
> Who am I to object?  I thought the purpose of this was that a user can,
> in her mode line code, call `frame-selected-window' to check whether the
> currently selected window really is the selected window (at least in a
> one-frame environment).

If we want that, we'll need some other way to get that info, since as
you point out it only worked for single-frame settings.

> IIUC display_mode_lines contains the only Lisp running code where the
                                 ^^
                                 ed

> selected window does not necessarily equal the selected window of its
> frame.

Yes.

> So it might be worth to fix this.

That's why I did it.


        Stefan

Message #95 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive
	face
Date: Sun, 23 Dec 2012 15:03:34 +0100

>> IIUC display_mode_lines contains the only Lisp running code where the
>                                  ^^
>                                  ed
>
>> selected window does not necessarily equal the selected window of its
>> frame.
>
> Yes.
>
>> So it might be worth to fix this.
>
> That's why I did it.

Sorry.  I was probably looking at the version in the release branch.
Maybe you should move it there, though.

martin

Message #98 received at 13225 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13225 <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Sun, 23 Dec 2012 10:40:31 -0500

> Sorry.  I was probably looking at the version in the release branch.
> Maybe you should move it there, though.

It's definitely not fixing a recent regression.  These bugs have been
with us for a very long time.


        Stefan

Message #103 received at 13225-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 13225-done <at> debbugs.gnu.org
Subject: Re: bug#13225: 24.3.50;
	Non-selected window has not mode-line-inactive face
Date: Fri, 04 Jan 2013 03:28:25 -0500

martin rudalics wrote:

> With emacs -Q do C-x 5 2.  The mode lines of both windows appear in
> `mode-line' face, regardless of which window is selected.

AFAICS, this is fixed.

The remainder of the discussion seems too free-form to make a useful bug
report, but please open a new one(s) summarising the issues if you
disagree (or reopen this one).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.