GNU bug report logs - #14604
24.3.50.1; Possibly incorrect behaviour of frame-selected-window

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 14604 in the body.
You can then email your comments to 14604 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: E Sabof <esabof <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50.1; Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 12:45:54 +0100

[Message part 1 (text/plain, inline)]

This works on 24.3, but on trunk all windows will be shown as "selected".

(setq-default
 mode-line-format
 '(:eval (if (eq (frame-selected-window)
                 (selected-window))
             "selected"
             "not-selected")))

I don't know which behavior is correct, but being able to find which is the
"really" selected window would be nice.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 16:02:01 +0300

> Date: Thu, 13 Jun 2013 12:45:54 +0100
> From: E Sabof <esabof <at> gmail.com>
> 
> 
> [1:text/plain Hide]
> 
> This works on 24.3, but on trunk all windows will be shown as "selected".
> 
> (setq-default
>  mode-line-format
>  '(:eval (if (eq (frame-selected-window)
>                  (selected-window))
>              "selected"
>              "not-selected")))
> 
> I don't know which behavior is correct, but being able to find which is the
> "really" selected window would be nice.

When the mode-line format is evaluated, Emacs makes its window the
selected window.  If it didn't, how could it show values for that
window in the mode line?

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

From: E Sabof <esabof <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 14:47:15 +0100

[Message part 1 (text/plain, inline)]

On Thu, Jun 13, 2013 at 2:02 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 13 Jun 2013 12:45:54 +0100
> > From: E Sabof <esabof <at> gmail.com>
> >
> >
> > [1:text/plain Hide]
> >
> > This works on 24.3, but on trunk all windows will be shown as "selected".
> >
> > (setq-default
> >  mode-line-format
> >  '(:eval (if (eq (frame-selected-window)
> >                  (selected-window))
> >              "selected"
> >              "not-selected")))
> >
> > I don't know which behavior is correct, but being able to find which is
> the
> > "really" selected window would be nice.
>
> When the mode-line format is evaluated, Emacs makes its window the
> selected window.  If it didn't, how could it show values for that
> window in the mode line?
>

(frame-selected-window) used to remain bound to the window which the user
would consider selected, and only (selected-window) changed. I don't know
whether it was a bug, or intentional.

If it was a bug, I suppose I could get the desired results with command
hooks.

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1; Possibly incorrect behaviour of
 frame-selected-window
Date: Thu, 13 Jun 2013 10:35:18 -0400

> This works on 24.3, but on trunk all windows will be shown as "selected".
> (setq-default
>  mode-line-format
>  '(:eval (if (eq (frame-selected-window)
>                  (selected-window))
>              "selected"
>              "not-selected")))

Indeed this doesn't work any more.  This was one of the very few places
where (eq (frame-selected-window) (selected-window)) was nil, and this
"invariant" is presumed at various places in the C code, so it was
a bug.

BTW, this worked in Emacs<24.3 if you wanted to highlight every frame's
selected-window, but not if you wanted to highlight "the one and only
selected-window".  For single-frame settings, there's no difference,
of course.

There is no alternative, yet.  We should probably provide some ad-hoc
primitives (call them maybe display-selected-window and
display-frame-selected-window) which return something like "the window
that was selected when we entered redisplay".


        Stefan

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

From: E Sabof <esabof <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 15:59:11 +0100

[Message part 1 (text/plain, inline)]

On Thu, Jun 13, 2013 at 3:35 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:

> > This works on 24.3, but on trunk all windows will be shown as "selected".
> > (setq-default
> >  mode-line-format
> >  '(:eval (if (eq (frame-selected-window)
> >                  (selected-window))
> >              "selected"
> >              "not-selected")))
>
> Indeed this doesn't work any more.  This was one of the very few places
> where (eq (frame-selected-window) (selected-window)) was nil, and this
> "invariant" is presumed at various places in the C code, so it was
> a bug.
>
> BTW, this worked in Emacs<24.3 if you wanted to highlight every frame's
> selected-window, but not if you wanted to highlight "the one and only
> selected-window".  For single-frame settings, there's no difference,
> of course.
>
> There is no alternative, yet.  We should probably provide some ad-hoc
> primitives (call them maybe display-selected-window and
> display-frame-selected-window) which return something like "the window
> that was selected when we entered redisplay".
>
>
>         Stefan
>

FWIW, the below seems to be working, although it still feels like an
omission.

Evgeni

(defvar user-selected-window nil)
(defun register-user-location ()
  (setq user-selected-window (selected-window)))
(add-hook 'post-command-hook 'register-user-location)

(setq-default
  mode-line-format
  '(:eval (if (eq user-selected-window (selected-window))
              "selected"
              "not-selected")))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 19:04:15 +0300

> Date: Thu, 13 Jun 2013 15:59:11 +0100
> From: E Sabof <esabof <at> gmail.com>
> Cc: 14604 <at> debbugs.gnu.org
> 
> (defvar user-selected-window nil)
> (defun register-user-location ()
>   (setq user-selected-window (selected-window)))
> (add-hook 'post-command-hook 'register-user-location)
> 
> (setq-default
>   mode-line-format
>   '(:eval (if (eq user-selected-window (selected-window))
>               "selected"
>               "not-selected")))

Does this work with mouse-autoselect-window?

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

From: E Sabof <esabof <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14604 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Thu, 13 Jun 2013 17:16:05 +0100

[Message part 1 (text/plain, inline)]

On Thu, Jun 13, 2013 at 5:04 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Thu, 13 Jun 2013 15:59:11 +0100
> > From: E Sabof <esabof <at> gmail.com>
> > Cc: 14604 <at> debbugs.gnu.org
> >
> > (defvar user-selected-window nil)
> > (defun register-user-location ()
> >   (setq user-selected-window (selected-window)))
> > (add-hook 'post-command-hook 'register-user-location)
> >
> > (setq-default
> >   mode-line-format
> >   '(:eval (if (eq user-selected-window (selected-window))
> >               "selected"
> >               "not-selected")))
>
> Does this work with mouse-autoselect-window?
>

Yes

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Wed, 30 Oct 2013 13:50:20 -0400

> (defvar user-selected-window nil)
> (defun register-user-location ()
>   (setq user-selected-window (selected-window)))
> (add-hook 'post-command-hook 'register-user-location)

> (setq-default
>   mode-line-format
>   '(:eval (if (eq user-selected-window (selected-window))
>               "selected"
>               "not-selected")))

That will usually work, except for corner-cases where redisplay happens
in the middle of a command, or when the selected window is modified
between commands (e.g. from a process sentinel).

You can make it reliable with the use of the new
`pre-redisplay-function' hook (instead of post-command-hook), which
I just added yesterday.

Of course, making it reliable doesn't mean it's not an omission.
I tend to agree that it would be good to provide access to that info
more directly.


        Stefan

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

From: E Sabof <esabof <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Wed, 30 Oct 2013 19:23:21 +0000

[Message part 1 (text/plain, inline)]

Thanks!

Evgeni


On Wed, Oct 30, 2013 at 5:50 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:

> > (defvar user-selected-window nil)
> > (defun register-user-location ()
> >   (setq user-selected-window (selected-window)))
> > (add-hook 'post-command-hook 'register-user-location)
>
> > (setq-default
> >   mode-line-format
> >   '(:eval (if (eq user-selected-window (selected-window))
> >               "selected"
> >               "not-selected")))
>
> That will usually work, except for corner-cases where redisplay happens
> in the middle of a command, or when the selected window is modified
> between commands (e.g. from a process sentinel).
>
> You can make it reliable with the use of the new
> `pre-redisplay-function' hook (instead of post-command-hook), which
> I just added yesterday.
>
> Of course, making it reliable doesn't mean it's not an omission.
> I tend to agree that it would be good to provide access to that info
> more directly.
>
>
>         Stefan
>

[Message part 2 (text/html, inline)]

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

From: E Sabof <esabof <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Wed, 30 Oct 2013 22:40:31 +0000

[Message part 1 (text/plain, inline)]

Seemed to work during my brief test. Am I right in assuming that it's going
to become `pre-redisplay-functions' if it goes into production?

Evgeni


On Wed, Oct 30, 2013 at 7:23 PM, E Sabof <esabof <at> gmail.com> wrote:

> Thanks!
>
> Evgeni
>
>
> On Wed, Oct 30, 2013 at 5:50 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:
>
>> > (defvar user-selected-window nil)
>> > (defun register-user-location ()
>> >   (setq user-selected-window (selected-window)))
>> > (add-hook 'post-command-hook 'register-user-location)
>>
>> > (setq-default
>> >   mode-line-format
>> >   '(:eval (if (eq user-selected-window (selected-window))
>> >               "selected"
>> >               "not-selected")))
>>
>> That will usually work, except for corner-cases where redisplay happens
>> in the middle of a command, or when the selected window is modified
>> between commands (e.g. from a process sentinel).
>>
>> You can make it reliable with the use of the new
>> `pre-redisplay-function' hook (instead of post-command-hook), which
>> I just added yesterday.
>>
>> Of course, making it reliable doesn't mean it's not an omission.
>> I tend to agree that it would be good to provide access to that info
>> more directly.
>>
>>
>>         Stefan
>>
>
>

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Wed, 30 Oct 2013 19:30:43 -0400

> Seemed to work during my brief test. Am I right in assuming that it's going
> to become `pre-redisplay-functions' if it goes into production?

No: use add-function to modify it.


        Stefan

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

From: E Sabof <esabof <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1;
 Possibly incorrect behaviour of frame-selected-window
Date: Fri, 1 Nov 2013 21:13:42 +0000

[Message part 1 (text/plain, inline)]

FWIW, I do like the new mechnsim. At the same time I think it offers little
utility for of 90% cases, while introducing complexity and opaqueness. I
wouldn't want it to become default for hooks.

Evgeni


On Wed, Oct 30, 2013 at 11:30 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca>wrote:

> > Seemed to work during my brief test. Am I right in assuming that it's
> going
> > to become `pre-redisplay-functions' if it goes into production?
>
> No: use add-function to modify it.
>
>
>         Stefan
>

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: E Sabof <esabof <at> gmail.com>
Cc: 14604 <at> debbugs.gnu.org
Subject: Re: bug#14604: 24.3.50.1; Possibly incorrect behaviour of
 frame-selected-window
Date: Sun, 13 Feb 2022 10:21:38 +0100

E Sabof <esabof <at> gmail.com> writes:

> This works on 24.3, but on trunk all windows will be shown as "selected".
>
> (setq-default 
>  mode-line-format
>  '(:eval (if (eq (frame-selected-window)
>                  (selected-window))
>              "selected"
>              "not-selected")))
>
> I don't know which behavior is correct, but being able to find which is the "really"
> selected window would be nice.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

In Emacs 29, we've introduced a new function
`mode-line-window-selected-p' for this use case (i.e., determining if
we're rendering the mode line for the currently selected window).  So
I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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