Re: Feature freeze and Tramp?

[Luc Teirlinck]

Stefan Monnier wrote:

   > auto-revert-mode causes the freeze.  This looks like a bug in
   > auto-revert-mode.  I will take a look at it and see whether I can fix it.

   The problem is likely to be that inhibit-quit is bound to non-nil while
   running timers (such as the auto-revert timer).  So you might want to
   wrap the auto-revert timer code with `with-local-quit'.

   But it would probably be better to use with-local-quit at the place where
   it's actually needed: around any potentially indefinitely blocking piece
   of code.  In this case it would be within Tramp around one of its calls
   to accept-process-output (or around one of the loops that calls
   accept-process-output).

I wrapped all relevant code with `with-local-quit'.  Now it is indeed
possible to quit, but the problem restarts 0 to auto-revert-interval
seconds later (as expected), unless one manages to kill all involved
buffers, or to disable Global Auto Revert Mode, in the meantime.

The trivial patch below completely solves the problem, but at the
expense of disabling the auto-reverting of remote files altogether.

The problem is that currently the Tramp handling of `file-exists-p'
and friends is very expensive if one has a slow connection, and
prohibitively expensive when not connected.  Indeed, then each single
call to `file-exists-p' and friends will take at least one full minute.

===File ~/autorevert-diff-1=================================
*** autorevert.el       04 Apr 2004 19:50:59 -0500      1.29
--- autorevert.el       09 May 2004 13:57:03 -0500      
***************
*** 311,316 ****
--- 311,317 ----
    (unless (buffer-modified-p)
      (let ((buffer (current-buffer)) revert eob eoblist)
        (or (and buffer-file-name
+              (not (file-remote-p buffer-file-name))
               (file-readable-p buffer-file-name)
               (not (verify-visited-file-modtime buffer))
               (setq revert t))
============================================================