From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize Date: Wed, 26 Aug 2015 15:01:22 +0200 Message-ID: <55DDB8A2.8020606@gmx.at> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> <83oahvfllk.fsf@gnu.org> <55DD663C.4040504@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440594141 30713 80.91.229.3 (26 Aug 2015 13:02:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2015 13:02:21 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 26 15:02:12 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 1ZUaLD-0002Vx-Hd for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 15:02:11 +0200 Original-Received: from localhost ([::1]:38181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUaLD-0001rL-0o for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Aug 2015 09:02:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUaL9-0001qx-6d for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 09:02:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUaL4-00009J-65 for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 09:02:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUaL4-00009C-3M for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 09:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUaL3-0003gi-RY for bug-gnu-emacs@gnu.org; Wed, 26 Aug 2015 09:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Aug 2015 13:02:01 +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.144059409414139 (code B ref 21333); Wed, 26 Aug 2015 13:02:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 26 Aug 2015 13:01:34 +0000 Original-Received: from localhost ([127.0.0.1]:38654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUaKc-0003fz-7v for submit@debbugs.gnu.org; Wed, 26 Aug 2015 09:01:34 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:58133) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUaKZ-0003fq-J9 for 21333@debbugs.gnu.org; Wed, 26 Aug 2015 09:01:32 -0400 Original-Received: from [62.47.255.145] ([62.47.255.145]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MaJPk-1ZAqYZ3KXI-00JvW6; Wed, 26 Aug 2015 15:01:27 +0200 In-Reply-To: X-Provags-ID: V03:K0:1zA3r3tgh3hVoYQXPV6TMwWhQ4pO8TWkqE88JeKJMt25PTU69Fy pj0RayDlX3X35UtQRcBLeO4kpD/DkIik/YRAm2aLHzXhe4sLX7o0FR25R2uROuoGjfFNAAs MB7MJ3qlaHllgybemus0Vsll54/LtIYt0T+oelPCDhJHIEpSFy4E7TlryUa6HGdRKrtkCTT +PMa70nyGNBOK2ghJ+l0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:Dh3P8fLWkFI=:6YR9Erl1J3Wn6j35RS17bO z6cwDcVj0ObdBgdPKiTpWfRnCS1flLmAOcQKxWdkpTxYQ582mDL//MmIob7pRD1KDRcPbic/T k88PqYMzEeQTv7wl+TVTeWh8MLJin3Ul1v/oXk2mJLq4ZzOYQlL+Nqsr7NIyosW8kbInyHp0E GayDo/zqyBYTTK9/XufXYNfIU0QqB2lw40xOL9zna/RPcGtWHfR/M0AzJAK9QMHGRUdt1Fjbf 562qaiYu3BS3gX/W7iRIuzaLoZbghPPIo92IVm2GdTgzNbZtk8PmtphKPpjqyqhvzFte04NwS Hx6RuvRha9Wyn5bnzt6OZgmmOKs3gAJR/SJa1VoHxohGO+tsvC9UAj+YZtlW28O21Fjz55iJJ tNrz7YkmRm9ZjcEvSEcEGwVx4oVW91Irj7r/sdVmypC9dPRBpQ0aIXz26nq7twq3GbsWhQOl0 2DCD5t0HYdhgXT+RjhAFSVMEHQcHTfa/m5S3EitBuO2HHtjw76qc/IZBeOjPU2WqU5+rEv8at z1rnaNQrHJarf/BoEYxmsNnjJ+fj4jW428QMb570vMmZPp2gReLCdVhvsgDEkaADrNHynfYlv WZPwImIUhXsurEbk6hXhDLHuziVx5b651JTz6FPGsPcyOp74jww6budtQJWGT3udTBtGHdFJI hUV5zzeT3uDhgihifte7K9kThynDSj1leGZ/2weKj3WAsRJ013o66M5SxRxxrxvQkzwVQKiE7 h0WqUdfI3RzYws3mrC4Q3dcpN5tuRQk7DtrRSQ== 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:105832 Archived-At: >>> So an alternative that doesn't need any hook is >>> simply to recompute the coordinates every time they are needed. It'= s >>> not like this calculation is expensive, is it? >> >> Correct. > > I disagree, if I understand correctly. My "correct" referred to Eli's "It's not like this calculation is expensive, is it?". I suppose we all agree on that. > The coordinates might be passed > to another program, for example, and then we simply don't know when > that program decides to use them, so we still need a way to update our= > (and its) idea of what the window size and position is, in my opinion.= I don't understand you here. IIUC Eli means that any application can store the old coordinates somewhere and easily compare them to the current ones in order to detect whether window sizes have changed. Even simpler: We could store the sizes in the window structure. This way prepare_menu_bars would simply walk the window tree of each frame to detect whether the size of any window has changed, call the functions on =91window-size-change-functions=92 and afterwards (better when redisplay completed) store the current size values into the old ones. The functions on the hook, OTOH, could check for each window individually whether and how its size changed. The advantage of this approach is that we never accumulate any fake size changes. >> So =91window-size-change-functions=92 is dispensable. > > Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly, > assumed that pre-redisplay-function is run many times per redisplay > call, but that appears to be incorrect. The huge majority of > redisplays call it just once, and that makes the overhead negligible. We can declare =91window-size-change-functions=92 obsolete and suggest to= use =91pre-redisplay-function=92 instead. Still we'd have to support it = for quite some time. > So what's the way forward, assuming my paperwork ever gets here? > - document window-size-change-functions aren't called for mini-windo= w resizes =2E.. and maybe neither when the menu or tool bar wrap. Yes (if we decide to not change anything else). > - document window-configuration-change-hook isn't called for > mini-window resizes No (because we nowhere say that `window-configuration-change-hook' is called for resize operations). > - document set-window-configuration doesn't call > window-size-change-functions if nothing changed No (because IIRC we never document fixed bugs). > - fix set_window_configuration not to set the window size change fla= g > unless there was an actual size change Unless we decide to move that check to prepare_menu_bars as I sketched above. > - wishlist item: call pre-redisplay-function between > grow/shrink_mini_window and the actual X repaint, rather than before. Are you sure? If prepare_menu_bars is called before auto-resizing the minibuffer window, then =91window-size-change-functions=92 wouldn't catch= those auto-resizes either. > - mark window-size-change-functions as obsolete and see whether > anyone complains? This will happen if we don't provide a good subsitute. > + if (w->pixel_left !=3D XFASTINT (p->pixel_left) || > + w->pixel_top !=3D XFASTINT (p->pixel_top) || > + w->pixel_width !=3D XFASTINT (p->pixel_width) || > + w->pixel_height !=3D XFASTINT (p->pixel_height)) You still didn't explain why you find it necessary to compare the pixel_left and pixel_top values. martin