Let mode-line packages distinguish the selected-window

Let mode-line packages distinguish the selected-window

[Jonas Bernoulli]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

By now there are quite a few packages that give the mode-line a more
"modern" look, including powerline, spaceline, doom-modeline, mood-line
and my moody.

  https://github.com/milkypostman/powerline
  https://github.com/TheBB/spaceline
  https://github.com/seagle0128/doom-modeline
  https://gitlab.com/jessieh/mood-line
  https://github.com/tarsius/moody

Something that many, if not all, of these packages have in common is
that they use images to give the mode-line a more "graphical" look.

The purely textual parts of the mode-line change their color based on
whether the respective window is the selected window by using one of
the faces mode-line or mode-line-inactive.

The colors of certain images also have to change based on whether the
window is selected or not.  Please look at the attached screenshot to
see why that is so.


[-- Attachment #2: mode-line-image-color.png --]
[-- Type: image/png, Size: 32235 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2089 bytes --]


The problem is that the functions that are being called while the
mode-line-format is being processed cannot tell whether their window is
"the" selected window because *every* window is temporarily selected
before its mode-line-format is being processed.

To deal with this the packages mentioned above resort to using several
hook functions and advice to keep track of "the" selected window and
then they do something like:

  (eq (selected-window) remembered-selected-window)

Because keeping remembered-selected-window up-to-date involves several
hooks and advises this is rather ugly and fragile.  The value of
remembered-selected-window often isn't actually correct because getting
these hooks and advises right is hard and maybe even impossible.

For an example see for example:
https://github.com/milkypostman/powerline/blob/6ef4a06c3c583045accbc957b6f449b7c0c57cd8/powerline.el#L530-L584

It would be nice if Emacs could instead bind a variable that is
accessible from lisp to the window that will be the selected window
again once we are done updating the mode-line of this and other windows.

This should probably happen in display_mode_lines().  Actually this
function does already save the selected-window in another variable
before it changes the value of this variable, but it only does so for
its own use.

  Lisp_Object old_selected_window = selected_window;
  ...
  struct window *sel_w = XWINDOW (old_selected_window);

Later this function decides what face to use like so:

      /* 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),
			 NILP (window_mode_line_format)
			 ? BVAR (current_buffer, mode_line_format)
			 : window_mode_line_format);

The result of this decision unfortunately also isn't accessible from
lisp.

In summary, please add a way for functions that format elements of the
mode-line to determine whether these elements are going to be used in
the selected or some other window.  Maybe there is a better way to do
that than what I suggested above.

Thanks!
Jonas

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

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Sat, 26 Oct 2019 15:38:19 +0200
> 
> It would be nice if Emacs could instead bind a variable that is
> accessible from lisp to the window that will be the selected window
> again once we are done updating the mode-line of this and other windows.
> 
> This should probably happen in display_mode_lines().  Actually this
> function does already save the selected-window in another variable
> before it changes the value of this variable, but it only does so for
> its own use.
> 
>   Lisp_Object old_selected_window = selected_window;
>   ...
>   struct window *sel_w = XWINDOW (old_selected_window);
> 
> Later this function decides what face to use like so:
> 
>       /* 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),
> 			 NILP (window_mode_line_format)
> 			 ? BVAR (current_buffer, mode_line_format)
> 			 : window_mode_line_format);
> 
> The result of this decision unfortunately also isn't accessible from
> lisp.
> 
> In summary, please add a way for functions that format elements of the
> mode-line to determine whether these elements are going to be used in
> the selected or some other window.  Maybe there is a better way to do
> that than what I suggested above.

Do you have a patch that works for you?  If so, could you show it?

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.
So a working patch, which was tested with the packages you mention,
would go a long way towards resolving the issue.

Thanks.

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

[Stefan Monnier]

> To deal with this the packages mentioned above resort to using several
> hook functions and advice to keep track of "the" selected window and
> then they do something like:

AFAIK since Emacs-24.4 only one hook is needed:

    (add-function :before pre-redisplay-function
                  (lambda (_)
                    (setq remembered-selected-window (selected-window))))
or
    (add-hook 'pre-redisplay-functions
              (lambda (_) (setq remembered-selected-window (selected-window))))

> Because keeping remembered-selected-window up-to-date involves several
> hooks and advises this is rather ugly and fragile.

With `pre-redisplay-function(s)` is should be "easy and reliable".

> In summary, please add a way for functions that format elements of the
> mode-line to determine whether these elements are going to be used in
> the selected or some other window.

Despite what the above may suggest, I fully agree: while it's now easy
to "roll your own", this is a common need and we should provide this
info directly.


        Stefan

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

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> To deal with this the packages mentioned above resort to using several
>> hook functions and advice to keep track of "the" selected window and
>> then they do something like:
>
> AFAIK since Emacs-24.4 only one hook is needed:

Well it seems I (or any of the maintainers of the other packages,
really) should have asked a bit earlier.  oO

>> Because keeping remembered-selected-window up-to-date involves several
>> hooks and advises this is rather ugly and fragile.
>
> With `pre-redisplay-function(s)` is should be "easy and reliable".

That's very promising indeed.  The minibuffer window needs to be handled
a bit differently, I think:

    (defun moody--set-active-window (_)
      (let ((win (selected-window)))
        (unless (minibuffer-window-active-p win)
          (setq moody--active-window win))))

    (add-hook 'pre-redisplay-functions #'moody--set-active-window)

>> In summary, please add a way for functions that format elements of the
>> mode-line to determine whether these elements are going to be used in
>> the selected or some other window.
>
> Despite what the above may suggest, I fully agree: while it's now easy
> to "roll your own", this is a common need and we should provide this
> info directly.

That would be nice. (And no Eli, I don't have a patch ready.  Not much
of a C guy.  Not at all really.)

But even though I suggested something like that, I feel the
remembered-selected-window approach is a bit hackish.  IMO it would be
nicer if instead of that variable regular selected-window would return
"that window" while a new function/variable named something like
mode-line-window returned the "window whose mode-line is currently being
updated".  But that would be a breaking change, so maybe not.

  Jonas

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

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Sat, 26 Oct 2019 21:27:29 +0200
> Cc: emacs-devel@gnu.org
> 
> > Despite what the above may suggest, I fully agree: while it's now easy
> > to "roll your own", this is a common need and we should provide this
> > info directly.
> 
> That would be nice. (And no Eli, I don't have a patch ready.  Not much
> of a C guy.  Not at all really.)

Well, you were "a C guy" enough to suggest where to make the change...

Anyway, feel free to submit a feature request via report-emacs-bug.

> But even though I suggested something like that, I feel the
> remembered-selected-window approach is a bit hackish.  IMO it would be
> nicer if instead of that variable regular selected-window would return
> "that window" while a new function/variable named something like
> mode-line-window returned the "window whose mode-line is currently being
> updated".  But that would be a breaking change, so maybe not.

Yes, maybe not.  And I think the variable you want should actually be
a function.

But that's the easy part; the hard part is to make sure the value does
what Lisp code called from mode-line expect.

Thanks.

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

[Stefan Monnier]

> That's very promising indeed.  The minibuffer window needs to be handled
> a bit differently, I think:
>
>     (defun moody--set-active-window (_)
>       (let ((win (selected-window)))
>         (unless (minibuffer-window-active-p win)
>           (setq moody--active-window win))))
>
>     (add-hook 'pre-redisplay-functions #'moody--set-active-window)

I don't understand what this is about.  From this all I can see is that
moody--active-window will always be nil, so it's clearly not quite right ;-)

This matters if we want to provide the info from the C code: we'd better
make sure we provide the right info then, but if different packages need
slightly different info we're in trouble.  This said, AFAICT,
minibuffer-window-active-p can be used later on so I get the impression
that the hook I suggested would provide enough info that you can easily
derive moody's specific flavor of that info.

> But even though I suggested something like that, I feel the
> remembered-selected-window approach is a bit hackish.  IMO it would be
> nicer if instead of that variable regular selected-window would return
> "that window" while a new function/variable named something like
> mode-line-window returned the "window whose mode-line is currently being
> updated".

Maybe you're right, tho I'm not sure really which of the two options
would be better in an ideal world.

> But that would be a breaking change, so maybe not.

Indeed, I think this ship has sailed so we don't need to figure out
which option is best.


        Stefan

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

[martin rudalics]

 > 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.  To get rid of the 'with-selected-window'
'minibuffer-selected-window' should accept an optional argument in
order to skip the

&& MINI_WINDOW_P (XWINDOW (selected_window))

check.

martin

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 26 Oct 2019 23:10:53 +0200
> 
> (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.  To get rid of the 'with-selected-window'
> 'minibuffer-selected-window' should accept an optional argument in
> order to skip the
> 
> && MINI_WINDOW_P (XWINDOW (selected_window))
> 
> check.

If we are going to add this feature as a C primitive, it should
ideally free the Lisp programmers from jumping through any additional
hoops, IMO.  So the above should be done in C instead, before
returning the value.  If some applications may want the minibuffer
window and others won't, we should make the function accept an
optional argument to select between these two alternatives.

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

[martin rudalics]

 > If we are going to add this feature as a C primitive, it should
 > ideally free the Lisp programmers from jumping through any additional
 > hoops, IMO.  So the above should be done in C instead, before
 > returning the value.  If some applications may want the minibuffer
 > window and others won't,

This is for applications that want to know the "usually" selected
window while the minibuffer window is selected.  It's still unclear to
me what 'minibuffer-selected-window' should really return in the first
place.  Its doc-string

   Return window selected just before minibuffer window was selected.

is misleading because, while the minibuffer is active, I always can
select a window that is not minibuf_selected_window and then select
the minibuffer window again.

 > we should make the function accept an
 > optional argument to select between these two alternatives.

The current version would be for users to evaluate right now.  If it
suits their needs, we can always provide it as a primitive.

martin

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

[Jonas Bernoulli]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That's very promising indeed.  The minibuffer window needs to be handled
>> a bit differently, I think:
>>
>>     (defun moody--set-active-window (_)
>>       (let ((win (selected-window)))
>>         (unless (minibuffer-window-active-p win)
>>           (setq moody--active-window win))))
>>
>>     (add-hook 'pre-redisplay-functions #'moody--set-active-window)
>
> I don't understand what this is about.  From this all I can see is that
> moody--active-window will always be nil, so it's clearly not quite
> right ;-)

You are mistaken.  moody--active-window is NEVER set to nil.

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

[Jonas Bernoulli]

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

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

[Stefan Monnier]

>>> That's very promising indeed.  The minibuffer window needs to be handled
>>> a bit differently, I think:
>>>
>>>     (defun moody--set-active-window (_)
>>>       (let ((win (selected-window)))
>>>         (unless (minibuffer-window-active-p win)
>>>           (setq moody--active-window win))))
>>>
>>>     (add-hook 'pre-redisplay-functions #'moody--set-active-window)
>>
>> I don't understand what this is about.  From this all I can see is that
>> moody--active-window will always be nil, so it's clearly not quite
>> right ;-)
>
> You are mistaken.  moody--active-window is NEVER set to nil.

Duh!  I read nil instead of `win`!


        Stefan

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

[martin rudalics]

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

Running your example in an unmodified Emacs _without_ the hook you
sketched above gets me _two active_ mode-lines here (on a windowing
system that gives focus to a frame when the mouse enters it).  Running
it with the hook gets me an active mode-line for the window of the
focussed frame only.  I can't tell which of these is more distracting.

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

Accessible only within the evaluation of 'mode-line-format'.

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

So maybe we should just provide a function called 'mode-line-active-p'
that returns non-nil when the window whose mode-line is just processed
is considered active (whether that decision is right or wrong) and not
talk about the selected window in the first place.

martin

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

[Jonas Bernoulli]

> Running your example in an unmodified Emacs _without_ the hook you
> sketched above gets me _two active_ mode-lines here (on a windowing
> system that gives focus to a frame when the mouse enters it).  Running
> it with the hook gets me an active mode-line for the window of the
> focussed frame only.  I can't tell which of these is more distracting.

That's the behavior I see too and I am not sure which I prefer either.
It probably would make sense to officially support both variants, add
a control an option and make sure it is always respected (i.e. that
weird code like what I posted thoes not have an effect).

> Accessible only within the evaluation of 'mode-line-format'.

That's where its needed, yes.  If callable and called in other contexts
then the value can be undefined as far as I am concerned.

>> 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.
>
> So maybe we should just provide a function called 'mode-line-active-p'
> that returns non-nil when the window whose mode-line is just processed
> is considered active (whether that decision is right or wrong) and not
> talk about the selected window in the first place.

That would be perfect for packages such as moody and powerline, but of
course the code you posted might be useful in other contexts as well.

  Thanks!
  Jonas

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

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Sun, 27 Oct 2019 22:13:50 +0100
> 
>   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.

Are you saying that you want the actual mode-line face to be exposed
to Lisp, not the selected window of the selected frame?

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

[martin rudalics]

 > That's the behavior I see too and I am not sure which I prefer either.
 > It probably would make sense to officially support both variants, add
 > a control an option and make sure it is always respected (i.e. that
 > weird code like what I posted thoes not have an effect).

Looks like some initialization problem.  Here, with emacs -Q when I do
C-x 5 2 followed by C-h f and then move the mouse to the first frame,
both windows get the active face.  Clicking now into the first frame's
window, makes that window the only active window.  Moving the mouse now
into the second frame's window makes both windows inactive.  Clicking
now into the second frame's window makes that window active and from
now on moving the mouse between the two frames activates the window on
the frame that has the mouse cursor in it.

Note that in all cases "window" stands for the "normal" and not the
minibuffer window.  Tested with a MinGW Windows 10 build of Emacs 26.

martin

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

[Jonas Bernoulli]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Sun, 27 Oct 2019 22:13:50 +0100
>>
>>   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.
>
> Are you saying that you want the actual mode-line face to be exposed
> to Lisp, not the selected window of the selected frame?

Checking whether Emacs was already doing that after all was the
last thing that I checked before I started this thread, so yes.

Doing that the way Martin suggested sounds like a good idea to me:

>>> So maybe we should just provide a function called 'mode-line-active-p'
>>> that returns non-nil when the window whose mode-line is just processed
>>> is considered active (whether that decision is right or wrong) and not
>>> talk about the selected window in the first place.

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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 29 Oct 2019 10:27:52 +0100
> 
> Note that in all cases "window" stands for the "normal" and not the
> minibuffer window.  Tested with a MinGW Windows 10 build of Emacs 26.

"Focus-follows-mouse" (a.k.a. "active window tracking") on MS-Windows
has several quirks, and some details depend on how exactly did you
turn that feature on.  So what you see may be part of those quirks,
not something about which Emacs has any say.

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

[martin rudalics]

 > "Focus-follows-mouse" (a.k.a. "active window tracking") on MS-Windows
 > has several quirks, and some details depend on how exactly did you
 > turn that feature on.  So what you see may be part of those quirks,
 > not something about which Emacs has any say.

The behavior is exactly the same with Debian's Xfce.  And since it
happens only when 'minibuffer-depth' is greater zero, it's hardly
caused by a misbehavior of the windowing system.

martin

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

[Eli Zaretskii]

> Cc: jonas@bernoul.li, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 29 Oct 2019 19:05:59 +0100
> 
>  > "Focus-follows-mouse" (a.k.a. "active window tracking") on MS-Windows
>  > has several quirks, and some details depend on how exactly did you
>  > turn that feature on.  So what you see may be part of those quirks,
>  > not something about which Emacs has any say.
> 
> The behavior is exactly the same with Debian's Xfce.

Good for you, but I wrote what I wrote because I don't see it here.

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

[martin rudalics]

 > Good for you, but I wrote what I wrote because I don't see it here.

Then try the following: With emacs -Q do C-x 5 2 followed by C-h f and
via Alt-TAB switch back to the first frame.  Here both frames get the
active mode-line face.

Now in the first frame do C-h f, do a mouse click in the second frame
and via Alt-TAB switch back to the first frame.  Here both frames get
the inactive mode-line face.

martin

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

[Eli Zaretskii]

> Cc: jonas@bernoul.li, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 30 Oct 2019 09:14:13 +0100
> 
>  > Good for you, but I wrote what I wrote because I don't see it here.
> 
> Then try the following: With emacs -Q do C-x 5 2 followed by C-h f and
> via Alt-TAB switch back to the first frame.  Here both frames get the
> active mode-line face.
> 
> Now in the first frame do C-h f, do a mouse click in the second frame
> and via Alt-TAB switch back to the first frame.  Here both frames get
> the inactive mode-line face.

The latter part I don't see: I get only one inactive frame.
As for the former, I'm not sure it's a bug.  It certainly doesn't look
like uninitialized variable to me: too consistent.

Anyway, this is a tangent, and we don't have to argue about it.