emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

selected-frame and selected-window


From: Stefan Monnier
Subject: selected-frame and selected-window
Date: Tue, 20 Nov 2012 15:37:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]