* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
[not found] ` <20230704132719.3251EC11DCA@vcs2.savannah.gnu.org>
@ 2023-07-04 14:16 ` Robert Pluim
2023-07-04 14:42 ` Michael Albinus
0 siblings, 1 reply; 6+ messages in thread
From: Robert Pluim @ 2023-07-04 14:16 UTC (permalink / raw)
To: emacs-devel; +Cc: Michael Albinus
>>>>> On Tue, 4 Jul 2023 09:27:18 -0400 (EDT), Michael Albinus <Michael.Albinus@gmx.de> said:
Michael> branch: master
Michael> commit b34f9a44393a331c866268d93b16ad69567a3cd4
Michael> Author: Michael Albinus <michael.albinus@gmx.de>
Michael> Commit: Michael Albinus <michael.albinus@gmx.de>
Michael> Apply remote-file-name-access-timeout in desktop.el and recentf.el
Michael> * doc/emacs/files.texi (File Conveniences):
Michael> * doc/emacs/misc.texi (Saving Emacs Sessions):
Michael> Mention remote-file-name-access-timeout.
Michael> * doc/misc/tramp.texi (Frequently Asked Questions): Add note.
Michael> * etc/NEWS: Explain use of 'remote-file-name-access-timeout' in
Michael> desktop.el and recentf.el.
Michael> * lisp/desktop.el (desktop-access-file): New defun.
Michael> (desktop-restore-file-buffer): Use it.
Michael> * lisp/recentf.el (recentf-access-file): New defun.
Michael> (recentf-keep-default-predicate): Use it.
This is a good change, although I wonder if we should set
`remote-file-name-access-timeout' non-nil by default, maybe something
relatively conservative like 60 seconds?
(I also see you use `natnump' for
`remote-file-name-access-timeout'. Is 0 a sane value to allow, I think
it would cause immediate timeout?)
Robert
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
2023-07-04 14:16 ` master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el Robert Pluim
@ 2023-07-04 14:42 ` Michael Albinus
2023-07-04 15:41 ` Robert Pluim
0 siblings, 1 reply; 6+ messages in thread
From: Michael Albinus @ 2023-07-04 14:42 UTC (permalink / raw)
To: Robert Pluim; +Cc: emacs-devel
Robert Pluim <rpluim@gmail.com> writes:
Hi Robert,
> This is a good change, although I wonder if we should set
> `remote-file-name-access-timeout' non-nil by default, maybe something
> relatively conservative like 60 seconds?
See the discussion in bug#64401. Initially, I've proposed a default of
30 seconds (IIRC); Eli replied with a proposal of 10 seconds.
But this is theory. If a connection is already established, a small
value of even 1 second would suffice. OTOH, if you need the initial
connection phase (f.e. during Emacs startup), with a slow connection to
the remote host, 60 seconds might be too short. And think about
multi-hops, where the initial connection phase could last longer.
That's why I've decided for the nil value, which is also the equivalent
to the current behavior - no timeout. But this is not set in stone, if
people believe another value is godd, then let's try it.
Btw, I've thought also about supporting connection-local values for
remote-file-name-access-timeout. For a fast connection you set it to 10
seconds, for another connection you use a larger value. Not implemented
yet, I don't know whether users want such a fine-grained customization.
> (I also see you use `natnump' for
> `remote-file-name-access-timeout'. Is 0 a sane value to allow, I think
> it would cause immediate timeout?)
Yes, an immediate timeout.
> Robert
Best regards, Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
2023-07-04 14:42 ` Michael Albinus
@ 2023-07-04 15:41 ` Robert Pluim
2023-07-04 16:29 ` Eli Zaretskii
2023-07-04 16:40 ` Michael Albinus
0 siblings, 2 replies; 6+ messages in thread
From: Robert Pluim @ 2023-07-04 15:41 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel
>>>>> 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. If it turns out to be too short, for some
people, then they can adjust their local value, no?
Michael> Btw, I've thought also about supporting connection-local values for
Michael> remote-file-name-access-timeout. For a fast connection you set it to 10
Michael> seconds, for another connection you use a larger value. Not implemented
Michael> yet, I don't know whether users want such a fine-grained customization.
YAGNI. Iʼd wait until people ask for it.
>> (I also see you use `natnump' for
>> `remote-file-name-access-timeout'. Is 0 a sane value to allow, I think
>> it would cause immediate timeout?)
Michael> Yes, an immediate timeout.
OK. I donʼt see the utility of that, but itʼs your code :-)
Robert
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
2023-07-04 15:41 ` Robert Pluim
@ 2023-07-04 16:29 ` Eli Zaretskii
2023-07-04 17:28 ` Robert Pluim
2023-07-04 16:40 ` Michael Albinus
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2023-07-04 16:29 UTC (permalink / raw)
To: Robert Pluim; +Cc: michael.albinus, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
2023-07-04 15:41 ` Robert Pluim
2023-07-04 16:29 ` Eli Zaretskii
@ 2023-07-04 16:40 ` Michael Albinus
1 sibling, 0 replies; 6+ messages in thread
From: Michael Albinus @ 2023-07-04 16:40 UTC (permalink / raw)
To: Robert Pluim; +Cc: emacs-devel
Robert Pluim <rpluim@gmail.com> writes:
Hi Robert,
> >> (I also see you use `natnump' for
> >> `remote-file-name-access-timeout'. Is 0 a sane value to allow, I think
> >> it would cause immediate timeout?)
>
> Michael> Yes, an immediate timeout.
>
> OK. I donʼt see the utility of that, but itʼs your code :-)
No intention, just coder's laziness :-)
I'll fix it next time I'll touch the code.
> Robert
Thanks, Michael.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el
2023-07-04 16:29 ` Eli Zaretskii
@ 2023-07-04 17:28 ` Robert Pluim
0 siblings, 0 replies; 6+ messages in thread
From: Robert Pluim @ 2023-07-04 17:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael.albinus, emacs-devel
>>>>> On Tue, 04 Jul 2023 19:29:39 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> 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.
Eli> But the behavior we retain isn't hanging: by default desktop.el
Eli> doesn't save and doesn't restore buffers that visit remote files, so
Eli> users will not see any effect of this timeout, unless they enable
Eli> restoration of such buffers.
OK, thatʼs less severe.
Eli> It might be a good idea to mention this new option in the doc string
Eli> of desktop-files-not-to-save. Here, done.
Iʼve been inspired to reword some documentation as well :-)
Robert
--
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-07-04 17:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <168847723857.12043.8020935461264507935@vcs2.savannah.gnu.org>
[not found] ` <20230704132719.3251EC11DCA@vcs2.savannah.gnu.org>
2023-07-04 14:16 ` master b34f9a44393: Apply remote-file-name-access-timeout in desktop.el and recentf.el Robert Pluim
2023-07-04 14:42 ` Michael Albinus
2023-07-04 15:41 ` Robert Pluim
2023-07-04 16:29 ` Eli Zaretskii
2023-07-04 17:28 ` Robert Pluim
2023-07-04 16:40 ` Michael Albinus
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.