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.