bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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@gnu.org-20121218190556-x9wmq083vwecgu0f
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
  `configure --with-gcc (4.6) --no-opt'

martin

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> Date: Wed, 19 Dec 2012 09:12:15 +0100
> From: martin rudalics <rudalics@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),

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

>   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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Drew Adams]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Drew Adams]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

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


        Stefan

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Drew Adams]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: martin rudalics <rudalics@gmx.at>,  13225@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?

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  13225@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.

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> Date: Thu, 20 Dec 2012 18:24:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 13225@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"?

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> Date: Fri, 21 Dec 2012 10:15:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 13225@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.

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> Date: Fri, 21 Dec 2012 15:24:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 13225@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.

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Stefan Monnier]

> 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

 > 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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Eli Zaretskii]

> Date: Thu, 20 Dec 2012 10:59:00 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 13225@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.

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[martin rudalics]

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

bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face

[Glenn Morris]

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