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: Thu, 27 Aug 2015 09:59:04 +0200 Message-ID: <55DEC348.8080306@gmx.at> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440662438 23889 80.91.229.3 (27 Aug 2015 08:00:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2015 08:00:38 +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 Thu Aug 27 10:00:27 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 1ZUs6h-0001ui-3H for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 10:00:23 +0200 Original-Received: from localhost ([::1]:59779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUs6g-0006PC-MX for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 04:00:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUs6X-0006Nq-JJ for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 04:00:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUs6P-0007xW-Jk for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 04:00:13 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUs6P-0007xB-Gq for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 04:00:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUs6O-0003DI-Iw for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 04:00:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Aug 2015 08:00:04 +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.144066235512268 (code B ref 21333); Thu, 27 Aug 2015 08:00:04 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 07:59:15 +0000 Original-Received: from localhost ([127.0.0.1]:39623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs5a-0003Bn-Vz for submit@debbugs.gnu.org; Thu, 27 Aug 2015 03:59:15 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:51252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUs5Y-0003Bf-Jy for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 03:59:13 -0400 Original-Received: from [62.46.213.30] ([62.46.213.30]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHso5-1ZRrHP1fYr-003dPn; Thu, 27 Aug 2015 09:59:10 +0200 In-Reply-To: X-Provags-ID: V03:K0:UNIYLgL7u/wRgrTZy+oO/9JCXELJbyrRAz3GGo0xTODD3g6cwrW L9c/VPun6wqfDPBkKoHfZ0n22Ny8mix9uGF6k9aLYrdehxW2XrcELRRCYec3lfQvtQTXywV kAII+pXOiUyKhEwIFbyE5nsNpo/VgriNeL175umkif8uq0XgspfGM2NW3Gvuq9dAZXOXc0i 0u/ffAUB8TXUuEDnGRRUw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tAhelhIorxI=:mXXAI6QyokOeFAM1deS16x KtyBCvoXo55uHCCLUVOfLUqh2pMP2iD9fR2y8fo7NZNjgAhbbeirnruERpo/sLiT8t+NmJfuG APlaUeH6DU4YY9xmzRdawwvtFzxVVqHyz3NyUHEc4aRrPNkQiM00DiwawVEctBnR+w5bwUsKY mL3Ak3RCJh0srvsA4Luk+2P0gNJZif/cpUqfyKrP7ail02xyav/5hkUJdcNWVCZTKM4yDoHb2 aL0tJ2EBa8KPG5yZ7usiAno/SMqCjpNxAsDlsdvRLbnD4LXIxXCk5VTYrOO4Qvd5xMkgoF4+h 5bvt+MK0KeIqtEpP0LdTRAnjMPlAmP8uzD9L/m3rsYhRa+OykOl3NWFzld1t9Rl66x+IwyDau 2cuuEG0RfETI1z2ZExRqQDwKRKpUOG5RuX1UFPsWwqpqNOsegP+LwUJvAKL4Ag1Rp+vqSdehH cWs9HiNBfka3L654DgYqGKmfA6bBZTxzXJuzS3g+Ezu4EV/XODEbXK+AQD+OSfn4oTxfgaOnR OhyT7CqejwPmyExXaHfX78AQDcvIOnYRNTD/biU2ZVlgS751Ih9eVwfAW1fDgLLeKh7ucaNoW fRhl4OFoEgwvApH3zWUsi57jYIFhm7DmAB5BkcSXnZ6Vq8AdOnlIpHOxjEw3VxGLqWJfXyzbz wK75pSz1aoFF6fhwnjbr3V/sDstBkxUIxONqsg26Jx3+d862VGdwhWAm/Rm8eYHVjCPbzAYYC lsOrzFNBaOk3HI9ACORAV6MxzW2kyXXGsKLe+g== 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:105865 Archived-At: > I understood Eli differently. If I'm not misquoting him, his suggestio= n was > to "simply recompute the coordinates every time they are needed". My > objection to that is that in many applications, you don't know when th= e > coordinates will be needed without changing other programs. There's no need to ever recompute coordinates. They are here all the time. What's needed is to record previous coordinates and to compare them with the actual ones. >> 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 >> =E2=80=98window-size-change-functions=E2=80=99 and afterwards (better= when redisplay >> completed) store the current size values into the old ones. > > Would (window-size) return the old or the new size values? All existing functions (like =E2=80=98window-size=E2=80=99) would obvious= ly remain unchanged. We would provide a new function, say =E2=80=98window-old-size= =E2=80=99, to return the width or height of a window at the time the last redisplay finished. > Is there consensus for keeping pre-redisplay-function? Sure. It's been only added in 2013. > windows.texi: > @defvar window-configuration-change-hook > A normal hook that is run every time you change the window configurati= on > of an existing frame. This includes splitting or deleting windows, > *changing the sizes of windows*, or displaying a different buffer in a= > window. Damn. > I think it's at least possible to read that as applying to window resi= ze > operations. At least. >>> - document set-window-configuration doesn't call >>> window-size-change-functions if nothing changed >> >> No (because IIRC we never document fixed bugs). > > Are you sure? It occurs to me I should have said "remove the bit in th= e > documentation that says window-size-change-functions is always called = by > set-window-configuration". It's not about documenting the bugfix, but > undocumenting the old bug. You're right again. I suppose that what we wanted to say there is that we always call =E2=80=98window-configuration-change-hook=E2=80=99. >>> - wishlist item: call pre-redisplay-function between >>> grow/shrink_mini_window and the actual X repaint, rather than before= =2E >> >> Are you sure? If prepare_menu_bars is called before auto-resizing th= e >> minibuffer window, then =E2=80=98window-size-change-functions=E2=80=99= wouldn't catch >> those auto-resizes either. > > That's why I consider it "wishlist". My Christmas wish is to be told > whenever the X rectangle corresponding to my Emacs window has changed,= just > before the X server is told about the change. I still don't understand: Do you mean that =E2=80=98pre-redisplay-functio= n=E2=80=99 is called in the wrong place? Where else would you call it? > Should that be impossible? As far as I can tell, the documentation rea= ds > like it should be possible. At least some people make use of it, if in= ways > you probably think useless. > > I consider the documentation to be more authoritative than current > behavior: if a feature should work according to the documentation, but= > doesn't, I think the right thing to do is almost always to fix the fea= ture > and then, afterwards, discuss whether it should be removed. If we can fix the feature, yes. >>> - mark window-size-change-functions as obsolete and see whether >>> anyone complains? >> >> This will happen if we don't provide a good subsitute. > > Wait, don't you mean that will happen if we do provide a good substitu= te? If =E2=80=98pre-redisplay-function=E2=80=99 can do the job it's a good su= bstitute. >>> + 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. =2E.. > Reasons for calling pre-redisplay-function in these cases: Mouseover, = if > you need more than text properties give you. Cursor warping. X hacks. = It's > what the previous code did, so I didn't dare change it. But this would imply that we also had to care about the case where a window's body width or height changes. Discriminating that is pretty difficult since we don't store that in a window configuration. And even the body width remains unchanged when I move a window's scroll bar from the left to the right. martin