emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

auto-revert-mode and tramp file handlers


From: Luc Teirlinck
Subject: auto-revert-mode and tramp file handlers
Date: Sun, 9 May 2004 12:34:27 -0500 (CDT)

>From one of my earlier messages:
   
   I do not know whether the following problem is connected to the update
   or not.

   Visit a file using the /ssh:address@hidden:FILENAME syntax.  When the file
   is displayed, close your connection.  Obviously, now tramp is not
   going to be able to function normally anymore.  But what happens is
   that Emacs now appears to freeze.  It does not even respond to C-g
   anymore, and I had to kill it from the command line.  Is this really
   unavoidable?  Closing one's connection forgetting that one has active
   trap buffers _is_ sometimes going to happen, so the behavior is a
   nuisance.

The above only happens when auto-revert-mode is enabled.  (Again,
sorry for forgetting to double check using emacs -q).

A problem is that tramp seems to handle functions like file-exists-p
and file-readable-p by trying to connect for 60 seconds and then
throwing an error if the connection has been closed.  I believe that
both functions strictly speaking should return nil in the given
situation.  In the case of file-exists-p that is because it is
impossible to figure out the file's attributes.  From the Elisp
manual:

 -- Function: file-exists-p filename
This function returns `t' if a file named FILENAME appears to exist.
This does not mean you can necessarily read the file, only that
you can find out its attributes.

If there is no way to quickly check whether the connection has been
closed, and if so, return nil instead of throwing an error, then I
believe that maybe we should just disable auto-reverting for remote
files.  (This is trivial, using `file-remote-p'.)  I believe that at
the very least there should be an option to disable auto-reverting for
remote files, because it can be very costly for people with slow
connections.

Sincerely,

Luc.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]