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: Sun, 28 Oct 2018 09:59:05 +0100 Message-ID: <5BD57A59.2070502@gmx.at> References: <87pnxmyjgt.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> <87a7o6ewxw.fsf@mail.linkov.net> <5BA9E378.9090105@gmx.at> <871s9hjvgn.fsf@mail.linkov.net> <5BAB487D.1000303@gmx.at> <87zhuzgx9u.fsf@mail.linkov.net> 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 1540717096 336 195.159.176.226 (28 Oct 2018 08:58:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2018 08:58:16 +0000 (UTC) Cc: 32672@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 28 09:58:12 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 1gGgtf-0008PO-A3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Oct 2018 09:58:11 +0100 Original-Received: from localhost ([::1]:39327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGgvl-0003sH-Eq for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Oct 2018 05:00:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGgvc-0003rO-A3 for bug-gnu-emacs@gnu.org; Sun, 28 Oct 2018 05:00:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGgvU-0006ID-Tz for bug-gnu-emacs@gnu.org; Sun, 28 Oct 2018 05:00:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42388) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gGgvS-0006Fq-9v for bug-gnu-emacs@gnu.org; Sun, 28 Oct 2018 05:00:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gGgvS-0008Kz-4Z for bug-gnu-emacs@gnu.org; Sun, 28 Oct 2018 05:00: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: Sun, 28 Oct 2018 09:00: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.154071716231979 (code B ref 32672); Sun, 28 Oct 2018 09:00:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 28 Oct 2018 08:59:22 +0000 Original-Received: from localhost ([127.0.0.1]:46646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGgun-0008Jj-RA for submit@debbugs.gnu.org; Sun, 28 Oct 2018 04:59:22 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:36099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGguk-0008JU-US for 32672@debbugs.gnu.org; Sun, 28 Oct 2018 04:59:19 -0400 Original-Received: from [192.168.1.101] ([212.95.5.102]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJByE-1gJQjW1tgA-002oZE; Sun, 28 Oct 2018 09:59:08 +0100 Original-Received: from [192.168.1.101] ([212.95.5.102]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJByE-1gJQjW1tgA-002oZE; Sun, 28 Oct 2018 09:59:08 +0100 In-Reply-To: <87zhuzgx9u.fsf@mail.linkov.net> X-Provags-ID: V03:K1:LwR3Fx6z++0tmjVKIajNuasfTJ3NjHKTPfF7yru9UYgQZRdAj49 /+jmi8AP4Rg8OBxQtmhPmymUd8N9V5G9BrASlwXeq6lPu7vlyRnwexc7q6LNgccjLDmXdhx wSRIY3RiGWXWikFARBQ9pBjrdtSPuWTxdzIm5elucB0JWG/Vs7YilH4A9tu/57qnrz1rJ67 2Rcax/NPR87K7ylXs8wDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:RbFKWtixwFA=:zBZMnANNpeXhhay/zsY9pi y2+dPchahHnWCieVJ96nO2JDpxeChkGjlX810G62podNXAZGJuOvG07CAfd2B8iZuCKRabpiA xj4u2RKNmYZoqnfCbxf8Qbd8bsEWc9JQU+WQw88KYVKoz4dhkZ0O1sm8SBuxIuHuFjJ47aE9n 56uEISjSYJabnZxWALeLqb7mhZM4G8iOTa9TpJtdSV3YXVT8uABVjIU6Vku1VcEyT9uD+Mieu 2MODYW3xdhV9YHzXlNh1CsWLh+/j6AbOqutJ11fQZniwkBcwvUA8m8z+rpvIcFLLU0bIB/4qp 5Ds/+EYNehkqgDp/E2uATjCISRHgK7/ctU6YY7PbANFFM59Nj5yvVGI7NrIB9Aw07RQHSLiuj VXRLCkaXpl7vYiJZ4I0srNPR4sakFsgPLLi/gLVk89m4aTSH61JiEAMT0Nueeh8PrSJHiLtVt Ci1AB8MLJ7njYFsvUHhomapcdKe07bb/13XzuhYGkCgFPxJR5wGxMDjcqamOyqbs1uAd6RCiP VyJSagTnW/hFw7uFu200GSQfd0IRjT98w4wdVcjTEZL9/cwL29qqc7jkEO7SZuAxooLW/V7Rj qPo0KzDk280kBv34g6dt64ff1b8qtGDGDKudbUSGhSDfe5B6uzQlnxhFpGdBbElS3xVBqxKau T9xyrXpM6cw8dnmpd4zrAj1EuFbYNDqCAnIHeEMad87maF12CoLwtKe+KmqPoOYzCo4THk7UI UP3ogp13bwRaTeK0V6HCXKHo+i+KTC2aLFHjuEtBdXkTBEgqhVmsWlJtAbIxlYN2Y9zrCvVx 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:151733 Archived-At: >>> Your proposed window-state-change-functions would match window-state-get >>> very well, e.g. it could call the hook with an argument containing alist >>> of values that really changed, where elements of the alist could have >>> the same keys as in alist returned from window-state-get, >> >> Retaining the nomenclature of 'window-state-get' is part of the plan. >> But I'm not sure whether we want to retain all of what is recorded in >> a window state. ... > Here is a complete implementation that works well when tested > on display-buffer-directionally in bug#32790 But tying this to the execution of commands misses the point that we would have to react to state changes whenever a frame is redisplayed. That is, we would miss all asynchronous, non-command-bound changes in a frame. What 'window-state-change-functions' would have to do IMO is: (1) Record, for each frame, whether window states might have changed since the last redisplay of the frame. That means to set a frame's flag whenever the buffer of a window, its selectedness or its start point changed. The reason I'd do this is to avoid the costly pre-analysis in (2), for example, after each self-insertion or any other change of buffer text. (2) During redisplay, check whether that flag was set and if so compare all windows on that frame with the state recorded during last redisplay. As we do for 'window-size-change-functions' already now but also check all window related things like those from (1). If and only if something changed, run the functions on 'window-state-change-functions' providing them information of what has changed - a new window w was made, the buffer of window w has changed and b was its buffer during last redisplay, w was selected and ww was the window selected during last redisplay and so on. Or just give them the old state with, say, window buffers instead of window buffer names and the previous and next buffers of each window elided (these would be too costly to maintain and analyze, I think). Thereafter, record the new state of the frame and clear the flag. This would improve on the current 'window-configuration-change-hook' in two regards: We'd run it less often (remember the number of calls you cited earlier) and we'd run it more accurately (that is, only when and always when something did really change). The hard part to code such a thing is _how_ to provide the information of what has changed. There are three major elements: (a) Windows that were added. Trivial. (b) Windows that were deleted. Trivial. (c) Windows where something changed (size, buffer, start position, dedicatedness, a window parameter, 'quit-restore' ???, ...). Non-trivial. Note that not providing that information will mean that the function run by the hook would have to manually compare the old state with the present one in order to find out what has changed, much as what they would do for size changes already now. > (it doesn't handle > window-point because then the hook is called too often): I suppose we could but only when it's written back, that is, changing point of the buffer shown in the selected window wouldn't count but writing it back into 'window-point' when selecting another window would. But in principle I agree with what you mean here. martin