emacs-devel
[Top][All Lists]
Advanced

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

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


From: Michael Albinus
Subject: Re: Auto-revert on remote files: disabling timers temporarily?
Date: Mon, 31 May 2004 22:43:44 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Luc Teirlinck <address@hidden> writes:

> Michael Albinus wrote:
>
>    Of course, it doesn't make any sense for slow links. So there should
>    be an option enabling/disabling auto-reverting for remote files, as
>    proposed by Kai.
>
> That would be trivial to do.  I believe it would be OK if the default
> were to disable and if the docstring gave suitable warning that
> enabling can cause problems on slow connections.

Sounds OK to me.

> If we go for an option, then another question is whether
> autoreverting of remote directories is sufficiently fast on fast
> connections that, if both this option, say
> global-auto-revert-remote-files, and
> global-auto-revert-non-file-buffers are enabled, then remote
> directories should autorevert as well.

It depends. Nevertheless, with my proposed patch (disabling timers
temporarily) it would be handled as well: If auto-reverting of a
directory lasts more than 5 sec, next time it should occur the timer
is disabled. So it happens in periods of 10, or 15, or whatever
seconds. If it lasts too long, the user should disable it.

Maybe there should be an option for the time period auto-reverting is
acting on remote files/directories? In your case (slow conmnection),
every minute would be an appropriate value. In other cases, 10 sec or
even the todays 5 sec would be sufficient.

> Note that, if I enable autoreverting of remote files, then, even with
> the new Tramp version, I still get either a hang or an "Invalid base64
> data" error if I try to visit my second remote file using Tramp-ssh.
> I have a slow connection.  I do not get crashes any longer, however.

That's definitely a bug. It would be great if you could produce a
backtrace, and if you could provide involved Tramp buffers.

> Sincerely,
>
> Luc.

Best regards, Michael.




reply via email to

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