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

From: Boruch Baum <[email-masked]>
Date: Wed, 16 Sep 2020 16:11:04 -0400

On 2020-09-15 20:24, Eli Zaretskii wrote:
> > Date: Tue, 15 Sep 2020 12:12:39 -0400
> > From: Boruch Baum <[email-masked]>
> > Cc: [email-masked]
> >
> > > Maybe we should arrange it to actually auto-revert before being
> > > displayed.  I envision bug reports if we don't.
> >
> > Do you have a strategy or implementation in mind? Would adding a
> > function to `window-configuration-change-hook' do the trick (ie. catch
> > all relevant events)?
>
> Yes, I think so.

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.

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?

An inelegant solution that would cover most of the remaining events
would be to advise :after ~4 frame functions, and to add an element to
variable `move-frame-functions'.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0