From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Window change functions Date: Sat, 05 Jan 2019 11:18:14 +0100 Message-ID: <5C308466.2090207@gmx.at> References: <5C21FB4B.7030005@gmx.at> <5C249D21.7070508@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546683447 4886 195.159.176.226 (5 Jan 2019 10:17:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2019 10:17:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 11:17:23 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfj18-0001AH-My for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2019 11:17:22 +0100 Original-Received: from localhost ([127.0.0.1]:36658 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfj3F-0002tn-4p for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2019 05:19:33 -0500 Original-Received: from eggsout.gnu.org ([209.51.188.92]:58669 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfj2I-0002sJ-IV for emacs-devel@gnu.org; Sat, 05 Jan 2019 05:18:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfj2F-0006UF-CU for emacs-devel@gnu.org; Sat, 05 Jan 2019 05:18:34 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:48943) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gfj2F-0006Sz-40 for emacs-devel@gnu.org; Sat, 05 Jan 2019 05:18:31 -0500 Original-Received: from [192.168.1.101] ([46.125.249.122]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3vCA-1hX0PL0rze-00rWkh; Sat, 05 Jan 2019 11:18:17 +0100 In-Reply-To: X-Provags-ID: V03:K1:7O8bHCPVY+d+MYOQtP3e8GTlOWQIfsiZl2FjlUv6wVk2H88MRpS 8sI5RgT+9kDF944bVOnGrAVkaM/SisREhxqaQpI83ppmeGev7Zjn7bXZDuggyqjAZskUy3V gYlIdNvud7VifASgYBGEDO9CFyuTcVrlHRhOgiz4R3sHgD+TLi5/RKk/rXvhDkLq+iEHVsN G4vdZMUGmDM68BG51yO7w== X-UI-Out-Filterresults: notjunk:1;V03:K0:8otLVBcUrLg=:xA+I2lPb9syMLmVr6HIL/x W3CTik1GUB1NCwq5FMN/8C2V29KrRXH5URqJE1Qug926QF5oFRllmk2/YanvN6uqXer6adQzR UeygP5/0TcUkLj9fuIGRsmugrw5zVSiUUzKLGdYS99rf+to3da8p+6LMXASkGgychyeczC2xb jMXXjdFOmOU8Fg6+KyGcv6WKPrpcajumzYU0/kMeRyJ/MKwGtBbsvLyy3H8aklZp1Zks5X0Gq uKfS88WVrgb4iITfsF7qLK/27L9RuVF3a3rHO7G829j8Z4undzwHvw+8pfXTY9gbnyQFkruNz FE6lqaZqrBv6IIBVLsyHQNzTFwgPdO0JuvYSBRQov22Ys4eA2V2VD/T1rXEqpzDzGmud3xMWv yadDH6C9clZ2lIvm8hqj7htTTiY1PkRdf3BgrLPuH4+7Yk+vKHlwskl6SEGefjGv5OsK/LSqg NBIyILj46umPjH0VRX6IONs3LKAVnGdRXBEB1FBgxDH/heFASYb9kNURbOtYWykLrwyy/b6Uq eqMM5Jg2Ek9JWszibX73ZorCIOgjaabgsIHk8JpZosZQqzDw2bJUt6/1D3kG2HWHrtp/NymTp v+7Z/n1hURj91ZStQgw1ESAjAMX8m7gisYqy9F0SPVpI3ujhiTVyvrp3PatfTWByV+SoYzpbk v0vyDWQreCfjPWyP9C1yhR8uLnFoxN5GAwa2B0MpZg6OdJcpPl76SBjslXgMpANDRlOYAxr6z x4MQSi873XMV5nVB0nuZglLUKQ3kcQekfJad+uR90egGdTrxxeN54+Sc7/WfSCbEZ+T1xMiF X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232196 Archived-At: > I can't remember the last time I found save-window-excursion to be > useful, so I don't find this use case important. Taking into account how often it's used in our code base, this use case is important. But let's substitute 'set-window-configuration' for it, or 'window-state-put'. >> (2) 'balance-windows-area' is a good example for why we should delay >> calling size change functions IMO: Its intermediate steps are no= t >> really interesting for any client of that hook. > > This is indeed a valid case. While I do use balance-windows-area, I'm= > not sure how important this is, tho. It's one example for how many size changes and corresponding calls of 'window-configuration-change-hook' may happen in one and the same function call. >> (3) Delaying hooks and running them all in one bunch allows to >> reliably look at possibly related changes by consulting the >> 'window-old-...' functions. > > I don't understand this. If we run the hook right away, the old state= > is easy to get to as well, isn't it? But after running the hook what would be the "old state"? I provide four interrelated hooks and all of them need to know the old state. Running an arbitrary hook in between would invalidate any consistent notion of an "old state". >> (4) Some clients do the delaying themselves by putting an according >> function on 'post-command-hook'. This won't be needed any more >> with delayed execution. > > The flip side is that while it's currently easy to delay the execution= > using post-command-hook, it will be impossible to *un*delay the > execution with the new setup. That's what worries me. Since the hooks are run after 'post-command-hook' there's indeed no way to undelay them. But the effect of running that "something else" from 'post-command-hook' or from =E2=80=98window-configuration-change-hoo= k=E2=80=99 right away should be the same. >> Note that 'window-size-change-functions' are currently already run >> right in the middle of redisplay. Often, window sizes are correct >> only *after* redisplay. Think of minibuffer window resizing or > > OK, miniwindow resizing is a valid case. Here I'm not sure though (and Eli was completely sceptical about it). 'window-configuration-change-hook' happily lived decades without reacting to minibuffer size changes until someone turned up that stone. This is one of the areas that must be observed cautiously. > If we run window-buffer-change-functions eagerly (i.e. from > set-window-buffer, as well as when creating/deleting a window), then > it's easy to let the hook access the "old buffer" that's being replace= d > (we can even pass it as a parameter to the hook functions). But then we would have to run it for every single instance of 'set-window-buffer' or 'with-selected-window'. The main objective of the patch was to avoid precisely that (and to not fall into a similar trap when providing a window selection hook). >>> IIUC this hook is hence also run for changes to frame-selected-windo= w, >>> even when that frame is not selected? I wonder if it's a good idea.= >>> frame-selected-window is a fairly obscure detail, in my experience. >> If someone changes it separately (that is, sets it for a non-selected= >> frame), there is now a hook to trace that. > > Right, and my question is: why bother? I think it makes the API more > complex with zero benefit. Maybe - but why then provide a thing like 'frame-selected-window' in the first place? Anyway given the fact that one of our basic invariants is (eq (selected-window) (frame-selected-window (selected-frame))) there is also zero cost for the admittedly small benefit. >> He could try it though. > > Didn't notice anything funny. Thanks for trying. martin