GNU bug report logs - #21333
25.0.50; window-size-change-functions not called after mini-window resize

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 21333 <at> debbugs.gnu.org
Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize
Date: Fri, 28 Aug 2015 13:26:28 +0000

[Message part 1 (text/plain, inline)]

As I said, that would be the perfect solution!

On Fri, Aug 28, 2015 at 1:13 PM, Eli Zaretskii <eliz <at> 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.