selected-frame and selected-window

selected-frame and selected-window

[Stefan Monnier]

> This is assertion violation in redisplay_internal, here:
>       eassert (EQ (XFRAME (selected_frame)->selected_window,
>                    selected_window));
> This crash is probably of the kind you reported in the past, related
> to the selected-frame/selected-window issues.

I'm not sure is that assertion is actually right.

99% of the time the (frame-selected-window) is the same as the
(selected-window), but there are some exceptions.  So far I found two:

- one in the redisplay, where we change selected-frame (without changing
  selected-window) just to get the frame-local variables.  As soon as we
  drop frame-local variables, this one will disappear (e.g. it's gone in
  my local branch).
- one in the mode-line computation.  This one is nasty because it is
  visible to lisp: while running an (:eval <form>) element, we change
  selected-window (without changing frame-selected-window) to the window
  being redisplayed.  So in <form>, it is not always true that
  (eq (selected-window) (frame-selected-window)).  To some extent this
  could be a feature (lets you return different data for the mode-line
  depending on whether it's selected or not), but I'd rather get this
  information differently since it is so easy to assume that
  (eq (selected-window) (frame-selected-window)) without being aware of it.

There might be more cases: I added a whole bunch of `eassert's where the
assertion is refined to try and take the above discrepancies into
account, and those get caught occasionally.  I haven't managed to track
down their cause yet.  It might just be a bug in the assertions.


        Stefan

Re: selected-frame and selected-window

[Stefan Monnier]

> 99% of the time the (frame-selected-window) is the same as the
> (selected-window), but there are some exceptions.  So far I found two:

I just found and corrected (on trunk) a third case (in update_tool_bar).


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Tue, 20 Nov 2012 15:37:05 -0500
> 
> > This is assertion violation in redisplay_internal, here:
> >       eassert (EQ (XFRAME (selected_frame)->selected_window,
> >                    selected_window));
> > This crash is probably of the kind you reported in the past, related
> > to the selected-frame/selected-window issues.
> 
> I'm not sure is that assertion is actually right.

Well, "bzr annotate" says you added it ;-)

Should we just go ahead and remove it?  Inaccurate assertions are a
maintenance headache, to say nothing of user aggravation.

Re: selected-frame and selected-window

[Stefan Monnier]

>> > This is assertion violation in redisplay_internal, here:
>> >       eassert (EQ (XFRAME (selected_frame)->selected_window,
>> >                    selected_window));
>> > This crash is probably of the kind you reported in the past, related
>> > to the selected-frame/selected-window issues.
>> I'm not sure is that assertion is actually right.
> Well, "bzr annotate" says you added it ;-)
> Should we just go ahead and remove it?  Inaccurate assertions are a
> maintenance headache, to say nothing of user aggravation.

The rest of my message mentioned reasons why the equality is
sometimes broken.  Now, I tend to consider that those cases should be
considered bugs, because IIRC there are cases where we do rely on this
equality.  More specifically, I added such easserts in an effort to
track the origin of an error.

But to fix these bugs we need to figure out how to handle the "mode-line
:eval" case.


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Dec 2012 18:51:40 -0500
> 
> >> > This is assertion violation in redisplay_internal, here:
> >> >       eassert (EQ (XFRAME (selected_frame)->selected_window,
> >> >                    selected_window));
> >> > This crash is probably of the kind you reported in the past, related
> >> > to the selected-frame/selected-window issues.
> >> I'm not sure is that assertion is actually right.
> > Well, "bzr annotate" says you added it ;-)
> > Should we just go ahead and remove it?  Inaccurate assertions are a
> > maintenance headache, to say nothing of user aggravation.
> 
> The rest of my message mentioned reasons why the equality is
> sometimes broken.

Yes, I know.  But a broken assertion is a candidate for removal, IMO.

> Now, I tend to consider that those cases should be considered bugs,
> because IIRC there are cases where we do rely on this equality.

If you or someone else can describe those cases, we could use that
knowledge to modify the assertion or fix the bugs which violate it.

> More specifically, I added such easserts in an effort to track the
> origin of an error.

We are evidently unable to do that in a long time.  All we do is cause
user aggravation and add to maintenance load.

> But to fix these bugs we need to figure out how to handle the "mode-line
> :eval" case.

Do you have any practical suggestions for that?

Re: selected-frame and selected-window

[Stefan Monnier]

>> The rest of my message mentioned reasons why the equality is
>> sometimes broken.
> Yes, I know.  But a broken assertion is a candidate for removal, IMO.

Agreed.

>> Now, I tend to consider that those cases should be considered bugs,
>> because IIRC there are cases where we do rely on this equality.
> If you or someone else can describe those cases, we could use that
> knowledge to modify the assertion or fix the bugs which violate it.

I did describe them.  I actually just installed a tentative fix for
those problems.


        Stefan

Re: selected-frame and selected-window

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 Dec 2012 10:53:32 -0500
> 
> I actually just installed a tentative fix for those problems.

Great, thanks.