bug#35418: [PATCH] Don't poll auto-revert files that use notification

[Michael Albinus <michael.albinus@gmx.de>]

Mattias Engdegård <mattiase@acm.org> writes:

Hi,

> An example of a generalisation: We could add a buffer-specific
> variable that tells autorevert that yes, this buffer can rely on
> directory notifications despite not having a buffer-file-name. All
> modes to which this applies would need to set that variable.

I sympathize with this proposal. There shall be an indication that a
buffer could be auto-reverted by file notifications. This indication is
either a non-nil buffer-file-name, or a non-nil buffer-local variable
(let's call it buffer-auto-revert-by-file-notification-aware; I'm open
to any better name).

Non-file buffers which could be auto-reverted are those which provide a
buffer-stale-function. A short scan in vanilla Emacs shows
Buffer-menu-mode and dired-mode, which set buffer-stale-function.

Buffer-menu-mode does not use files, so it doesn't profit from file
notifications. One could write another kind of notification which fires
when buffers are created or deleted, but that's another story. And I
doubt it will be more useful than the current auto-reverting for buffer
lists.

So indeed, dired is left for vanilla Emacs. It shall set
buffer-auto-revert-by-file-notification-aware when a buffer is setup to
dired-mode. Other packages in the wild could do similar settings, think
about vc-dir or magit, which use their own machinery. Potentially, any
mode which uses (an own implementation of) revert-buffer, would be a
candidate for this kind of auto-revert.

Thinking about, I'm even not confident that a static value of this
indication is sufficient. In dired, it might be set to t when the dired
buffer is setup. But what if the dired buffer contains subdirectories?
Is it still possible to indicate this by file notifications over
default-directory? Don't know, maybe not, and the variable has to be set
to nil ...

Long story short: we shall start with dired, which sets a buffer-local
variable as indication, and we shall edocument this in the Elisp
manual. Let's see where we go.

Best regards, Michael.