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: Zoom: a window management minor mode -- best practices and questions Date: Wed, 09 May 2018 09:00:45 +0200 Message-ID: <5AF29C9D.4090902@gmx.at> References: <83muxioten.fsf@gnu.org> <5AEAB616.4040900@gmx.at> 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 1525849208 20902 195.159.176.226 (9 May 2018 07:00:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 May 2018 07:00:08 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Andrea Cardaci Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 09 09:00:03 2018 Return-path: Envelope-to: ged-emacs-devel@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 1fGJ4z-0005Hx-OZ for ged-emacs-devel@m.gmane.org; Wed, 09 May 2018 09:00:01 +0200 Original-Received: from localhost ([::1]:54850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGJ77-0004fS-1C for ged-emacs-devel@m.gmane.org; Wed, 09 May 2018 03:02:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGJ64-0004bp-7u for emacs-devel@gnu.org; Wed, 09 May 2018 03:01:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGJ5y-00054E-G2 for emacs-devel@gnu.org; Wed, 09 May 2018 03:01:08 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:37527) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fGJ5s-0004sN-68; Wed, 09 May 2018 03:00:56 -0400 Original-Received: from [192.168.1.100] ([213.162.73.208]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJSLz-1fIE6Z2ywV-0035AG; Wed, 09 May 2018 09:00:52 +0200 In-Reply-To: X-Provags-ID: V03:K1:9Gbp+sU1hnWGRcvToa3Gpxie1f25uoiB1yHYJiH2VtvZYh7BvTi R0b6gJWS2lSUqGR+uovkN8Xk0/OMXT9L2o8/nAAT8TYLD5nwqhkOz6nQkznm2LzbB3TkZ5g P5LAa81rKx9d1sS/V/MWeQIrUFqdyxjoTlQreiaKSgkXhyZgf+mdUC/2pRoniuf8KKmEJfz qhnxQ/K4b+2rRgL7y7UOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:VEDwI5ZVNog=:XkAJE8hOxsLJ0BjljvtVAy l8TJD5pi4dkGcI1fQeOu/+z0F2OQBmFxCu1FS9p4BJF9c9aPorA3GbdnYhSR3AxCR4Pn/kbjr O011UZJ6365MH61vjxpmlMWXQhM3RSVFSFoPOEpkeScBKDDiRWFJXHVn3NY0GgBIx2UA7GOd/ QqhqHElMxFVEA/LoMKDmNeK1q9fIKmz0dVtL5EY/nDN1fCqB0/ON2wUzGvRsXarUpnmmDRGEs C1J5b1kBLCYHVl8988WmEGa9ILziGWMQiyDNI66xPSHB5wKe4ZXf1ZOyEwaOYVhezv+D1+j8G jXnJ4RFJsoGcqxFofxVLKI7eauiIA/DwcZzdVx67ZCR/Kr6w3PthO5KyodWbbXgGwdlJx3NQB PTM/AvwJUeWCJIRZj8JWerUEDrPURP5NVkuZCBjMJpuT2cs/o20lePMga+Iv2DWNUXVzkd2UF MhMDg25B+F/wl0l3ceSkXbRxfdklV5EIfN2U8gwe9/V5ZxMWlISqRUccZk+A2O8FuzTOoBHnP b40OyN6DOikU9ftteWy1ptMLJtRB7kU80gYAsuhpIo3HdO4+h7oFXeFs4CYlv6OkxOR30fPmS Io2BJizVqtM4P4CpCTW8CArXXvalZZU5a5v0/2gVvmqK1kSSmF4/JNzVR6jp/IUPeCRHfMJtQ oBJ9WXxFBDia0IahM2WMo6P+NIjgCkJ578AkorFK3dNp24o+aX8/nOB5DKJ6bzFT4WpOqx8SC N1+s0FPwO8yUFOY649MJlGspfpmxhs6AxY5OPDYL3qofZzS0hYOoJfo34J0CjMEi6pdXdb+V X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.19 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:225162 Archived-At: > There's one problem with `buffer-list-update-hook` though, it gets > called (multiple times) even wen the buffer list is not changed, e.g., > simply by clicking in the buffer. Is this the expected behaviour? Yes and no. Some users accumulate several hundred entries in their buffer lists. For them, checking the buffer list every time a buffer is recorded could create an unnecessary performance burden. So it's expected that the function on the hook remembers the old buffer list and compares it against the new one if this is of any importance (I suppose that in many cases checking the head of the list is all that's needed). > Besides this, if there's no way to get rid of false positives in event > handling (i.e., a relayout is triggered but no actual change happened) > I guess I need a way to decide if a relayout is *really* needed. A > naive way would be saving the current window and buffer but I'm not > sure if we can do better. For example 'switch-to-buffer' does (select-window (selected-window))) in order to record the buffer it displays to make sure that a "false positive" is made when the selected window already displays the buffer. So saving the selected window and the buffer it displays is the best thing one can do. The Elisp manual mentions this as follows: However, when its NORECORD argument is `nil', `select-window' updates the buffer list and thus indirectly runs the normal hook `buffer-list-update-hook' (*note Buffer List::). Consequently, that hook provides a reasonable way to run a function whenever a window gets selected more "permanently". Since `buffer-list-update-hook' is also run by functions that are not related to window management, it will usually make sense to save the value of the selected window somewhere and compare it with the value of `selected-window' while running that hook. Also, to avoid false positives when using `buffer-list-update-hook', it is good practice that every `select-window' call supposed to select a window only temporarily passes a non-`nil' NORECORD argument. If possible, the macro `with-selected-window' (see below) should be used in such cases. martin