GNU bug report logs - #43412
[FEATURE] autorevert-only-if-visible [PATCH]

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Boruch Baum <boruch_baum <at> gmx.com>, martin rudalics <rudalics <at> gmx.at>
Cc: 43412 <at> debbugs.gnu.org
Subject: bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]
Date: Thu, 17 Sep 2020 16:13:52 +0300

> Date: Wed, 16 Sep 2020 16:11:04 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: 43412 <at> debbugs.gnu.org
> 
> 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.

> 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'.

Yes, I'd prefer to avoid such solutions.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.