GNU bug report logs -
#43412
[FEATURE] autorevert-only-if-visible [PATCH]
Previous Next
Full log
Message #41 received at 43412 <at> debbugs.gnu.org (full text, mbox):
On 2020-09-17 16:13, Eli Zaretskii wrote:
> > 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.
I'm needing now to focus on Rosh HaShanna preparations, and can let
emacs distract me for the next few days, but from memory, on tty emacs:
1) touch ~/foo
2) find it in emacs
3) bury the frame so it's not human-visible
3.1) OT: I find it useful to globally bind C-x 5 b to function
select-frame-by-name, because I do this routinely as part of my
workflow. Another option might be C-x 5 2.
4) M-! echo "bar" >> ~/foo
5) switch to the buried frame
6) Depending upon your timing, you'll need to wait up to
auto-revert-interval seconds for the buffer to be updated.
> > 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.
It maybe could all be solved if there were a hook for frame change of
state (eg. getting/losing focus, being raised/buried). It's surprising
to me that such events were never thought significant enough in emacs to
merit a hook.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
This bug report was last modified 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.