From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: yacoob@gmail.com, 7348@debbugs.gnu.org
Subject: bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
Date: Mon, 08 Nov 2010 21:24:27 +0200 [thread overview]
Message-ID: <831v6vobys.fsf@gnu.org> (raw)
In-Reply-To: <4CD7CBC8.9010103@gmx.at>
> Date: Mon, 08 Nov 2010 11:07:04 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Jakub Turski <yacoob@gmail.com>, 7348@debbugs.gnu.org
>
> > The call to do_pending_window_change at line 11397 in xdisp.c
> > (emacs-23 branch) seems to change selected_window because of the
> > following call chain, but the variable `w' in redisplay_internal still
> > points to the old selected window.
> >
> > redisplay_internal
> > -> do_pending_window_change
> > -> change_frame_size
> > -> change_frame_size_1
> > -> set_window_height
> > -> size_window
> > -> delete_window (/* Delete WINDOW if it's too small. */)
>
> That's bad. So basing redisplay_internal entirely on
>
> struct window *w = XWINDOW (selected_window);
>
> is inherently broken. But simply reassigning
>
> w = XWINDOW (selected_window);
>
> after every do_pending_window_change call is hairy since it changes the
> selected window under our feet, so any things done for the window that
> was selected before the call would probably have to be redone for the
> now selected window.
The only thing I see that uses selected_window and is done between
this line:
++redisplaying_p;
and the 1st call to do_pending_window_change is this call:
reconsider_clip_changes (w, current_buffer);
We could simply call reconsider_clip_changes again if we detect that
the selected_window changed after the call to do_pending_window_change.
The second call to do_pending_window_change is conditioned on
must_finish being zero, which I think cannot happen when this
situation hits.
And the third call to do_pending_window_change already goes back to
retry anyway.
So maybe there's no problem in updating the value of w in this case.
next prev parent reply other threads:[~2010-11-08 19:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 21:20 bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX Jakub Turski
2010-11-07 3:18 ` YAMAMOTO Mitsuharu
2010-11-07 10:34 ` martin rudalics
2010-11-08 1:43 ` YAMAMOTO Mitsuharu
2010-11-08 10:07 ` martin rudalics
2010-11-08 19:24 ` Eli Zaretskii [this message]
2010-11-09 7:43 ` martin rudalics
2010-11-09 16:57 ` Eli Zaretskii
2010-11-09 17:52 ` martin rudalics
2010-11-09 18:49 ` Eli Zaretskii
2010-11-10 7:18 ` martin rudalics
2011-02-07 17:26 ` Jakub Turski
2011-02-08 4:57 ` Eli Zaretskii
2011-02-08 7:23 ` Jan Djärv
2010-11-07 11:22 ` Jan Djärv
2010-11-07 19:05 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831v6vobys.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=7348@debbugs.gnu.org \
--cc=rudalics@gmx.at \
--cc=yacoob@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.