Ron Isaacson writes:
After a resize, I see TWO calls to change_frame_size with the
correct
dimensions, while delay == 1. Each of these sets the f->new_*
variables, along with size_change_pending, then returns. Then there's
a THIRD call, again with correct dimensions, when delay == 0; that
sets size_change_pending to 0 and then we go through a full redisplay.
redisplay_frame does:
depth = enter_redisplay_critical_section ();
and gets back a depth of 3. It proceeds all the way through the
CRITICAL REDISPLAY SECTION, then when it's done, calls:
exit_redisplay_critical_section (depth);
Now, I confirmed that just before that call, f->size_change_pending is
still 0. However, when exit_redisplay_critical_section does its
unbind_to business, specpdl_depth_counter starts at 13; by the time it
walks down to 3, f->size_change_pending has been reset to 1,
Hm. I wonder if it's not size_change_pending that has been reset to
1, but rather f has been reset to a frame where size_change_pending is
1! See the comment about size_change_pending in change_frame_size_1
at line 3437 of frame.c, but in change_frame_size we loop over all TTY
frames without resetting size_change_pending on frames != f at line 3460.
but the two f->new_* variables are still 0.
And this may make sense because change_frame_size was called on that
frame from the loop in redisplay.c at line 6719.
I gotta get some sleep, but I think that moving the reset of
size_changed_pending to the beginning of change_frame_size_1 might help.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta