Re: Let mode-line packages distinguish the selected-window

[Jonas Bernoulli <jonas@bernoul.li>]

martin rudalics <rudalics@gmx.at> writes:

>> I understand the general idea, but in the display code the devil is in
>> the details, and this particular place is tricky already.  One issue
>> that bothers me is what happens when we are in the minibuffer window.
>
> FWIW with Emacs 27 the form
>
> (or (eq (selected-window) (old-selected-window))
>     (and (not (zerop (minibuffer-depth)))
> 	 (eq (selected-window)
> 	     (with-selected-window (minibuffer-window)
> 	       (minibuffer-selected-window)))))
>
> should handle all concerns.

This works well.  I have already updated moody to use this approach when
possible.

But it won't give the desired behavior in some weird edge-case.  Another
package of mine did something weird which did trigger such an edge-case.
I already fixed that, but yet another package might do something similar
and actually have a legimite reason to do so.

More on that later, but first lets remember what we ultimately want.
Not that the above isn't useful in its own right but what the packages
that I mentioned really want to know is:

  Which face (mode-line or mode-line-inactive) is the mode-line of this
  window using?

That is of course closely related to the question:

  Is the is the "selected" window?

But the answer to the first question can not always be derived from the
answer to the second.

And here is a weird edge case where doing so is not possible:

  (add-hook 'pre-command-hook (lambda () (force-mode-line-update t)))

Sure that is weird, but that's not the point.  With this hook function
we can observe the following behavior:

1. Enter minibuffer.
2. Switch to another frame.  (Without leaving minibuffer first.)
3. Observe that the window which was the selected window before
   (1) now uses mode-line-inactive but your code snippet returns t.

I think the only 100% sure way to be able to answer the first question
is to record that decision at the time when it is made.  Emphasize on
both "that decision" (not some closely related one) and "at that time",
i.e. when CURRENT_MODE_LINE_FACE_ID_3 is being called by
display_mode_lines, then that value has to be saved in a way that is
accessible from lisp.

Now I am not saying this absolutely has to be done.  I am quite happy
with the above code.  But since I noticed this edge-case I though I
would point it out in case you decide that this is something we cannot
live with.

Cheers,
Jonas