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

[Pip Cet <pipcet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1903 bytes --]