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

[Boruch Baum]

On 2020-09-15 17:30, Eli Zaretskii wrote:
> > Date: Tue, 15 Sep 2020 00:07:28 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> >
> > +(defcustom auto-revert-only-if-visible nil
> > +  "If non-nil, suppress Auto-Revert Mode when a buffer isn't visible."
>
> "Visible" is ambiguous in this context.  I suggest "not displayed in
> any window" instead.  Or, better, just "auto-revert only if buffer is
> displayed" (which also solved a problem with double negation).

In the case of TTY emacs, only one frame seems possible to ever be
visible, but each and every frame seems to be considered, let's say
'displayed'. In that situation, this patch only auto-reverts buffers
displayed on windows of the actually 'displayed' TTY frame.

> > +  :version "28")
>               ^^^^
> "28.1"

Thanks. I had just taken a guess.

> > +                         (if (display-graphic-p) 'visible 
> > (window-normalize-frame nil)))))))
>
> Is the different treatment of GUI and TTY frames necessary here?

For users of TTY emacs (ahem, me), most assuredly. In TTY emacs, AFAICT
only one frame can ever be 'displayed' (actually visible), but function
`get-buffer-window-list' with argument ALL-FRAMES set to 'visible
returns all windows on all frames. From that function's docstring:

  --8<--cut here-(start)------------------------------------------- >8
  - ‘visible’ means consider all windows on all visible frames on
    the current terminal.
  --8<--cut here-(end)--------------------------------------------- >8

That behavior of function `get-buffer-window-list' may in turn be
because of the behavior of function `frame-visible-p', whose docstring
begins with:

  --8<--cut here-(start)------------------------------------------- >8
  Return t if FRAME is "visible" (actually in use for display).
  --8<--cut here-(end)--------------------------------------------- >8

But ends with the punch-line:

  --8<--cut here-(start)------------------------------------------- >8
  If FRAME is a text terminal frame, this always returns t.
  Such frames are always considered visible, whether or not they are
  currently being displayed on the terminal.
  --8<--cut here-(end)--------------------------------------------- >8

So since for the purposes of this patch, what matters is the actual user
experience, the distinction *was* needed.

  Off-topic: would anything constructive result if I submit a separate
  'complaint' about that behavior / judgment / decision that 'Such
  frames are always considered visible'?

> Btw, what will be the effect of this option?  Suppose some buffer was
> not displayed and missed its auto-revert opportunity.  Then I switch
> to it in some window -- will it appear with stale contents, or will it
> auto-revert before being displayed in the window?

I kind of mentioned this in my note: From my testing, at the instant an
un-reverted buffer is displayed, it is in its 'stale' state but is also
instantly considered for auto-revert. The *theoretical* maximum delay to
the auto-revert then being performed is based upon defcustom
`auto-revert-interval', whose default is five seconds. In practice, the
possible downsides are that: 1) it might be visually surprising to the
user to see the auto-revert occur; 2) if the user was very hurried to
type at wherever POINT was in the buffer, then the auto-revert would be
further delayed if defcustom `auto-revert-stop-on-user-input' was non-nil
(the default), and would only happen once the hurried typist pauses. In
my anecdotal use / testing / debugging, this has only every happened
when I consciously made the effort to race the auto-revert, but the
experience of a caffeinated or adrenaline-d user might be different.

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