From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs 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-ID: References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> <55DDB8A2.8020606@gmx.at> <55DEC348.8080306@gmx.at> <83bnds69e8.fsf@gnu.org> <83y4gw4l19.fsf@gnu.org> <83fv334tpi.fsf@gnu.org> <837fof4ktz.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ed2f80514b7051e5f08d4 X-Trace: ger.gmane.org 1440768442 8466 80.91.229.3 (28 Aug 2015 13:27:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 13:27:22 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 15:27:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVJgW-0000Mv-4e for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 15:27:12 +0200 Original-Received: from localhost ([::1]:47903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJgV-00057J-IF for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 09:27:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJgR-000572-Ve for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:27:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVJgO-0004Os-Ie for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:27:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVJgO-0004Oo-DN for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:27:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVJgN-0000r2-Ej for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 09:27:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Aug 2015 13:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21333-submit@debbugs.gnu.org id=B21333.14407683933246 (code B ref 21333); Fri, 28 Aug 2015 13:27:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 28 Aug 2015 13:26:33 +0000 Original-Received: from localhost ([127.0.0.1]:40897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJfs-0000qH-HA for submit@debbugs.gnu.org; Fri, 28 Aug 2015 09:26:33 -0400 Original-Received: from mail-io0-f169.google.com ([209.85.223.169]:33012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVJfp-0000q8-FS for 21333@debbugs.gnu.org; Fri, 28 Aug 2015 09:26:30 -0400 Original-Received: by iods203 with SMTP id s203so92603950iod.0 for <21333@debbugs.gnu.org>; Fri, 28 Aug 2015 06:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+D74bKvQ+P02p0ATMiZDL1jo5nCkGv7h6ap11UmVBYE=; b=BQeMHz1u0d7zyEDbRAfbQG1Hk69a5jxeAfyfzW9sjxVmwMXClLSN0XFkQXwaJBTVNm e9sqiN2c0V1XA+nyu3QqJl4U7B2ccBSe1Idj9FBB0WtL+cKpj+x9/l1jIF/CJFt3Ar57 kgoPFJK+eoGEN53yRWo790X55voy2aQufNqBXjjuIZqOmgUlSZ9swhPSCD+jQH6EQP4p rZyBc9tgXX8ocVySJKkyAjMvcHDQeS8yenWJqYol3Kht3kvTgkneLHttjIG+ifzME72i iN1nTCm4Vi/snewHdumk6dKzLjxEmyN5ju7CbY4HtmLcpwAyd2uGZP3vIIPEMhRBtNeb i95w== X-Received: by 10.107.132.139 with SMTP id o11mr13610972ioi.3.1440768388828; Fri, 28 Aug 2015 06:26:28 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Fri, 28 Aug 2015 06:26:28 -0700 (PDT) In-Reply-To: <837fof4ktz.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105916 Archived-At: --001a113ed2f80514b7051e5f08d4 Content-Type: text/plain; charset=UTF-8 As I said, that would be the perfect solution! On Fri, Aug 28, 2015 at 1:13 PM, Eli Zaretskii 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 --001a113ed2f80514b7051e5f08d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.=C2=A0 But how does that let you know what update_frame<= br> actually did?=C2=A0

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

1. set bre= akpoint in update_frame
2. "p x_sync($f)" (if neces= sary)
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 rig= ht 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
--001a113ed2f80514b7051e5f08d4--