From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel 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 Message-ID: <834jmjljws.fsf@gnu.org> References: <168847723857.12043.8020935461264507935@vcs2.savannah.gnu.org> <20230704132719.3251EC11DCA@vcs2.savannah.gnu.org> <87jzvf92yw.fsf@gmail.com> <87sfa3n3fg.fsf@gmx.de> <87fs638z0v.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, emacs-devel@gnu.org To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 04 18:30:35 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qGivD-000730-4X for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 18:30:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGiuT-0007X0-3r; Tue, 04 Jul 2023 12:29:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGiuP-0007VZ-ED for emacs-devel@gnu.org; Tue, 04 Jul 2023 12:29:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGiuP-00081N-2B; Tue, 04 Jul 2023 12:29:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=03oL5C3REAOHv1bitHhAKBGHgXuTRQ1ojetUI/StoZ0=; b=lVB38I7UdaiSk9NDB65L 0+ZSq6ryHw7wT4J6BLfzImRWdRYG8UrXhXVPY61ji3MoY5A246bl3DP+KMPn4STIQLVOcg0FvLcX1 lweeQeVlD/7bXJCKAgBb8XcRmt572lBuyxQdQlul5ELAjAev+nE9Lrl++qMw+L/5AApZ6wlzISVTt TY+1Lc9apvXze3Ghu0Tr7SB3B3GHFGvpHZUO0lZTZJhuNv6WjpBmoyaE6ayJG9EsXEd774cpK0T6F 4BNKat2nY6F0+BArPEEZ41uO9+a1qbpRGU8C8gUqjeewiDNwKKwYeHwEHdT7JrRC0qFn8EwhYtioq U1HzSGCa/iB96A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGiuN-0000A1-Rs; Tue, 04 Jul 2023 12:29:44 -0400 In-Reply-To: <87fs638z0v.fsf@gmail.com> (message from Robert Pluim on Tue, 04 Jul 2023 17:41:36 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307427 Archived-At: > From: Robert Pluim > 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 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.