emacs-devel
[Top][All Lists]
Advanced

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

Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop


From: Eli Zaretskii
Subject: Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
Date: Tue, 04 Jul 2023 19:29:39 +0300

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 04 Jul 2023 17:41:36 +0200
> 
> >>>>> On Tue, 04 Jul 2023 16:42:43 +0200, Michael Albinus 
> >>>>> <michael.albinus@gmx.de> said:
> 
> 
>     Michael> But this is theory. If a connection is already established, a 
> small
>     Michael> value of even 1 second would suffice. OTOH, if you need the 
> initial
>     Michael> connection phase (f.e. during Emacs startup), with a slow 
> connection to
>     Michael> the remote host, 60 seconds might be too short. And think about
>     Michael> multi-hops, where the initial connection phase could last longer.
> 
>     Michael> That's why I've decided for the nil value, which is also the 
> equivalent
>     Michael> to the current behavior - no timeout. But this is not set in 
> stone, if
>     Michael> people believe another value is godd, then let's try it.
> 
> Iʼm all for retaining backwards compatibility, but when the behaviour
> weʼre retaining is 'hang forever', I think we should consider putting
> in a default timeout.

But the behavior we retain isn't hanging: by default desktop.el
doesn't save and doesn't restore buffers that visit remote files, so
users will not see any effect of this timeout, unless they enable
restoration of such buffers.

It might be a good idea to mention this new option in the doc string
of desktop-files-not-to-save.  Here, done.



reply via email to

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