From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#32672: 27.0.50; image resize on window resizing Date: Mon, 24 Sep 2018 19:37:08 +0200 Message-ID: <5BA920C4.1060204@gmx.at> References: <87pnxmyjgt.fsf@mail.linkov.net> <87ftyfoakb.fsf@mail.linkov.net> <5B98B33D.7000605@gmx.at> <871s9ycnjl.fsf@mail.linkov.net> <5B9A15DA.5000403@gmx.at> <87efdxnfww.fsf@mail.linkov.net> <5B9B7253.5060808@gmx.at> <87pnxexr2m.fsf@mail.linkov.net> <5B9E1E0E.7070805@gmx.at> <87h8ip2eby.fsf@mail.linkov.net> <5B9F4DBD.5020009@gmx.at> <877ejjzr9s.fsf@mail.linkov.net> <5BA20763.8070305@gmx.at> <875zz1t6y1.fsf@mail.linkov.net> <5BA34D7E.4030509@gmx.at> <87fty3sp6a.fsf@mail.linkov.net> <5BA490E5.5090506@gmx.at> <87zhw9xjpx.fsf@mail.linkov.net> <5BA74E3D.5030903@gmx.at> <87va6wt79n.fsf@mail.linkov.net> <5BA89ED5.4050207@gmx.at> <83in2vb8dw.fsf@gnu.org> <5BA8D7AB.5030106@gmx.at> <83d0t3awqt.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1537810576 9940 195.159.176.226 (24 Sep 2018 17:36:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2018 17:36:16 +0000 (UTC) Cc: 32672@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 24 19:36:11 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4UmH-0002PI-21 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Sep 2018 19:36:09 +0200 Original-Received: from localhost ([::1]:46287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4UoN-0005QN-L3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Sep 2018 13:38:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4UoA-0005Gn-TY for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 13:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4Uo6-0008Dp-Qi for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 13:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48046) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g4Uo6-0008Dh-Mv for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 13:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g4Uo6-0003Bj-Eu for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 13:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Sep 2018 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32672 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32672-submit@debbugs.gnu.org id=B32672.153781064712207 (code B ref 32672); Mon, 24 Sep 2018 17:38:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 24 Sep 2018 17:37:27 +0000 Original-Received: from localhost ([127.0.0.1]:52304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4UnW-0003Ao-NF for submit@debbugs.gnu.org; Mon, 24 Sep 2018 13:37:26 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:49277) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4UnU-0003Ab-Nx for 32672@debbugs.gnu.org; Mon, 24 Sep 2018 13:37:25 -0400 Original-Received: from [192.168.1.100] ([212.95.5.41]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MEnX8-1fyRKS1GCQ-00G0rs; Mon, 24 Sep 2018 19:37:14 +0200 In-Reply-To: <83d0t3awqt.fsf@gnu.org> X-Provags-ID: V03:K1:0oQIpycOAJY5YtDubTQAX7SZTlYPWCWmZP3c9AaSxAK4AMSwOMF pfsha5TOMPfjelWFK6uWDL+TIHAh4wjUD9rW0gEPVaWzNkNILrXfpKcDZIBDaPn1xTly/gD zM+29giO/xvNpZTG+C+yR96w3GOe+sGt2QGYwixLTFLovZFgw+laFT3IIrMQtilF5JJR4Ko E474QOFQfvNsM3txN2E0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:OUv5HOEhDsI=:R/jGA9fW3/ngshJm6vtCxH sAxncroh/D9o5xrPK40bK92f78ueDE0c5ftycwSVQfUFpV9d/hh8TPJFgGhqOQTfVwD4Nes8J tj2t4HxPJ8NS5H5FclcWpAdSJuIFTj51CLgx0YU18a6FD8EZWlY7CwXPqypPFhbBjOBugK3k5 9b9SbHKCkhUVvDZ+p9WQuTl6ngMtdxahlw9xd58dy3S7BOZDqt/CEmNzLx0miyYc6C+zxb+Tr wSfM35l8PKXe9fmw1rzGd9pqsdUYZKyBoMR0V0mM8hcW0Q4JK/h97rvo+Q6K1vGHx2P+RNOew 77laailvfklx4NjG8GRvEF86EJpVXCme4u1neLWLANTqrz8wRc7csRBDURqK3y5bllPYKET+4 D5e2gvY7bUNCHEhu0vXWnAyM7Edz8m9r7VFh51g/Nxsx6aOvzXQgx1GI8RXPi3xTnWSPui6Ah ln6MKvBx7AzGOrOXycV1WgCXEpQWZ8aB7QT4i2hbDubHPTeIZoHyNJNgRAwHXyCTERufutVNG 7r+6Xe34Fl0lZteBVtUq4aBNwd/0y1BSyfj+se05OXw27/3Iz3/Vmy9AUVc86P5oIh5W7Gork XJdQI1hdM9xvp3HiJR7aMc9SMbpGiUaaWwsSKaYOOJAydcF1lWGi05cb1ATpvfOSbjS/ozAF0 pF9SgN3eeoRMyL5Qld8QD+VzhtBA/CWlXvEJlC/OIvq9fKZidsTaWSue8xqs5a9pmb7WnHnXw EDXG2TofoEqRMQKJa/jli1XN+TOzBdlhvs1XgF6MDuuvwx8Pyadr3NI+T1/Dmjciewr6HaPk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:150610 Archived-At: >> 'window-configuration-change-hook' is a great mess and is not >> display-related. > > It is for the purposes of this discussion, since it's related to > changes in what windows display which buffers and which frames show > what windows. The point I tried to make was that currently running that hook is not coupled to the eventual display of windows but to things that happen before. >> What users really need IMO is a single hook say >> 'window-state-change-functions' that we'd call in redisplay_internal >> in lieu of 'window-size-change-functions'. > > redisplay_internal knows very little about changes in window > configurations, so I predict using this new hook will be as messy as > with the existing ones. 'redisplay_internal' per se should not have to know anything about these changes. It would call a simple function that calculates for every window whether it already existed at the time of the last redisplay and whether one of its sizes, its position, buffer, point, or start position changed since then. In addition we could trace the state of its parameters and other things like its dedicatedness. >> We would run it if something in the state of a frame's root window >> changed (including size changes, changes of the windows' start >> positions and the selected window) and additionally provide a list >> of the differences in the frame's previous window state and the one >> redisplay is about to use. > > We'd need to compute this list of changes first, and for that we will > need a whole slew of new variables and flags. Currently, redisplay is > built on the opposite assumption: that each operation which could > potentially require redrawing some window(s) or frame(s) sets the > corresponding flags of the object that needs to be redrawn, without > any "explanation" of why that flag was set. As I said, redisplay would not have to care about that at all. It would simply call 'window-state-change-functions' where it calls 'window-size-change-functions' now. And running 'window-state-change-functions' would use one boolean set (among others) instead of where 'run-window-configuration-change-hook' gets called now and which it resets. Iff that boolean was set, it would start to find all windows where a relevant change occurred and run the functions. Buffer-locally iff a window shows the buffer for which the local hook was set and something changed for that window. The great advantage for users and application programmers would be that their functions would run once only and only if something really changed since last redisplay. Basically, it would extend the current behavior of 'window-size-change-functions' to all window changing functions. And we could extend it in the sense that the users may customize which changes should run their function without inventing future hooks for them (admittedly 'add-hook' would then need a fifth argument or some special interpretation of LOCAL for that). martin