bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize

[Pip Cet]

As I said, that would be the perfect solution!

On Fri, Aug 28, 2015 at 1:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> IOW, there are several ideas of what the screen looks like:
> 1. the glyph matrix etc.
> 2. what Xlib has been told the screen should look like
> 3. what the screen actually looks like.
>
> update_frame synchronizes (2) with (1). x_sync synchronizes (3) with (2).

Yes, I know.  But how does that let you know what update_frame
actually did? 

By actually looking at the screen to see what's on it.

1. set breakpoint in update_frame

2. "p x_sync($f)" (if necessary)

3. look at screen to see before-state

4. "finish"

5. "p x_sync($f)"

6. look at screen

It could do very little or nothing at all, and you need
to put a breakpoint at the right place (like the call to the
draw_glyphs method of the display interface) to see which parts are
being actually redrawn.

I can conclude that all parts that changed on the screen have been redrawn. You're right that I cannot conclude that the other parts have not been redrawn, so my method is of limited utility, but in this case, it works.

I agree with everything else you said in the last email.

Pip