From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#43412: [FEATURE] autorevert-only-if-visible [PATCH] Date: Fri, 18 Sep 2020 09:49:35 +0200 Message-ID: References: <20200915040728.77ufv7g6bekvrzqa@E15-2016.optimum.net> <83y2lb8648.fsf@gnu.org> <20200915153958.e2nry7dxl3pmu3k6@E15-2016.optimum.net> <83imcf82fy.fsf@gnu.org> <20200915161239.f3fb74daihpon64w@E15-2016.optimum.net> <83een37y21.fsf@gnu.org> <20200916201104.ktl6aukmpe5hk6g2@E15-2016.optimum.net> <83a6xo7dgv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34291"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43412@debbugs.gnu.org To: Eli Zaretskii , Boruch Baum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 18 09:50:51 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJBAP-0008lm-Ty for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Sep 2020 09:50:50 +0200 Original-Received: from localhost ([::1]:55052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJBAO-00035x-PY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Sep 2020 03:50:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJB9f-00034o-BF for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 03:50:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57401) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJB9e-0000Hq-4o for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 03:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kJB9e-0006T3-1c for bug-gnu-emacs@gnu.org; Fri, 18 Sep 2020 03:50: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: Fri, 18 Sep 2020 07:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43412 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 43412-submit@debbugs.gnu.org id=B43412.160041538524819 (code B ref 43412); Fri, 18 Sep 2020 07:50:01 +0000 Original-Received: (at 43412) by debbugs.gnu.org; 18 Sep 2020 07:49:45 +0000 Original-Received: from localhost ([127.0.0.1]:40711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJB9N-0006SE-1L for submit@debbugs.gnu.org; Fri, 18 Sep 2020 03:49:45 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:48527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJB9L-0006Ry-BY for 43412@debbugs.gnu.org; Fri, 18 Sep 2020 03:49:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600415376; bh=4kZwAJH4Af1v9ElSBt/Ldfxa3zNvEfcHlzZ42pI9Zts=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Aelfn4TV4Unn592Qf8xg/g72qDrHWFEb318ubV6U1JsE4vWjjDuobkp8v0B2dtnTn HGCY2YlNMdHEPVgrDhlxoYZQ+W66YovdetZulaGzH8LpP/0hPjErHCX2OUotlAPDxk qEmFVUlVxsVupQax9lEinIf7RE422Xceh1oKAZ+g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([46.125.249.44]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MmDEm-1kjgDA2zui-00iAhM; Fri, 18 Sep 2020 09:49:36 +0200 In-Reply-To: <83a6xo7dgv.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:pUb/KBIIabbdmRKkA3239GqGlPXIkPm8skzwq1Fskn2OhflqTRX ++LEKF8VB+Z3HGX5Qtm+46aoWiwMsLZmeGKRgIkzk/eRi9+/Y7h/Kf+fo4H+nyuIAhfd+3u 1c9ivVihf19RQxF23xTd6KwSKVmev993dBVmGX8TWpFqmvMFKbl1iBVXmJJuqAzz8uBNupB ERsjPomAOngfUjug8gcVA== X-UI-Out-Filterresults: notjunk:1;V03:K0:QqaFV3ywkLI=:wxx3lBFSbzeoeRg6ketxNr dcm+59cVN5UUuFhDroXD3ixO7siUXwavBDHoHO2HArQKzX6kXteydbAW/TX0sYQJu6H80FGhp vqCgkf6JN7pw0+YWpZEL8e/xetF2IvhN9X9lwYrTxVGZT7+AZWxHHP2BjrCxsBZlRIddw7E0T aEIIyhWql8h5rBjhv4jNWXbP8Pa8SOyaqSAlbwEiMpVStReiFlzM373cSE+PgOrcLw29j98Pn AfQAPB+2uv3dWqpTQEI86CjEHw2v8cxzqffMn+xfVSlJQf47A/v4YIJQ/gs/AVSqqrVNczqay E+KwqjPVedBNm7bGb7Mzj9KfLn5Kh537KOnv66tzKfeVcpsA1BgT/gAP1oXX43Kp1aLez/f0m rKUB83Rh+Pk7rGERv/u4ckFBKWuxwRwk2vNNynmp6SoZeFXk/J50DMlY1aHZCT0XagVCTgq4U p22imWVoGAEcA4qV9Z5he+Q/X6snxoecwOEbe/bs+obK3R10JF88SGysGtl87Qz06eTSz4sKT SMdfYVSK6Q0MjysFxBUlGSfLx1MXeFRVdm8zv+GjRikhQ4D0ybi5+f8XN/L8CXZ8OiWmkDIYZ CksOe/puYPqvoEooYf2WLPtc1cwZdWPTvTIvlbbM5U0FweL+R4WdYzMW/MoR/rRmuWdTmVR5L tnOeJGHMrZhxDCWqzWqgtWaJ5/nCQjDnSsquaRQxsNw1hZf0DlelBzu1jluCuk0jM4u4QP08g OOtYVS1HhEF5UBijidAhLrbU27ymb1e+zj62w6AdQvWFsOb0GA2yHGfeIqjRXvbdYYvVILCa X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:188270 Archived-At: >> It looks to me like that's not the case: my testing seems to show that >> it does catch cases of changing a buffer displayed in a window but does >> not catch changes of frames due to functions like `other-frame' or >> `select-frame'. >> >> So, the good news is that I've written the code that makes the >> improvement for the caught cases, and I can submit that. >> >> As for the cases of changing frames, a less-desirable option would be to >> preempt bug-reports by documenting the limitation. Auto-revert already >> has other curious limitations (eg. for dired buffers it doesn't operate >> _at__all_ on many types of file changes), and this limitation only >> introduces a delay, so by comparison its a pretty mild limitation. > > If we have no better way, we could document this as a limitation, > yes. But let's make one more attempt to solve this. > >> A better option would be able to catch frame-change events. I haven't >> found a straightforward way to trap that. Does such a method exist? > > Can you describe the problematic case in more detail? With that in > hand, perhaps Martin (CC'ed) could suggest a method. From what I've read so far, Baruch wants to react to two events only: A window displays another buffer and a window gets selected, where the latter subsumes anything like frame selection or switching, or a frame getting focus. The former should be handled by adding a function to 'window-buffer-change-functions'. The latter should be handled by adding a function to 'window-selection-change-functions'. When these added functions (probably it's one and the same function) are run, one can use 'window-old-buffer', 'frame-old-selected-window', 'old-selected-window' and 'old-selected-frame' to individually check what has changed since the last time. For example, to find out whether a window on the frame reported by 'window-buffer-change-functions' has changed its buffer, 'walk-window-tree' for that frame with a function that checks whether 'window-buffer' for any such window differs from 'window-old-buffer'. If it does differ, you probably want to check whether that buffer should be reverted. For 'window-selection-change-functions' you probably want to just check whether the buffer of the selected window of the reported frame should be reverted. I would avoid using 'window-configuration-change-hook' because that hook also triggers when a window changed its size. All hooks are described in detail in section "28.28 Hooks for Window Scrolling and Changes" of the Elisp manual. If you have any further questions, please ask. martin