Re: Auto-revert on remote files: disabling timers temporarily?

[Luc Teirlinck]

Michael Albinus wrote:

   In parallel to Kai, I've tried to find another solution. What about
   disabling timers during execution of a Tramp file name function?

With what intent?

Only to restore auto-reverting of remote files?  If so, would that
mainly be to help debug other problems or because there would appear
to be a real need to revert remote files?  Temporarily re-enabling
auto-reverting of remote files for debugging purposes can easily be
done by erasing one line in ` auto-revert-handler', namely:
(not (file-remote-p buffer-file-name))

On my connection a call to `file-readable-p' for a remote file takes
approximately .35 to .4 seconds.  It can take substantially longer
under less ideal conditions.  (For a local file it takes
substantially less than .001 second, it is essentially unmeasurable.)

With fifteen remote files and global-auto-revert-mode enabled, and the
default value of auto-revert-interval (five seconds)
auto-revert-buffers would essentially be running `file-readable-p' on
remote files constantly, disabling other timers.  This assuming that
no files ever would ever actually need to be reverted.

Actually reverting depends a lot on the size of the file.  For a
moderately sized file like streams.texi, it takes more than 15
seconds.  Again, it can take much longer under less than ideal
conditions.  This assumes that all the connection setup has already
been done.

`auto-revert-stop-on-user-input' only works _between_ taking care of
individual buffers.  So user input could be disabled for more than
fifteen seconds, sometimes _much_ more than that.  One could use
`with-local-quit' to allow interrupting with C-g, but the trouble
starts again 0 to 5 seconds later, so that is no big help.

Sincerely,

Luc.