bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]

[martin rudalics <rudalics@gmx.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