From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Hadsell Newsgroups: gmane.emacs.bugs Subject: Re: Inconvenience with TRAMP and recentf Date: Mon, 02 Jul 2007 11:08:21 -0400 Organization: Mt. Diablo Systems Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183388918 16947 80.91.229.12 (2 Jul 2007 15:08:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2007 15:08:38 +0000 (UTC) To: gnu-emacs-bug@ftp.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 02 17:08:36 2007 connect(): Connection refused Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I5NVz-0007kc-P0 for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Jul 2007 17:08:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5NVz-0001k7-BX for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Jul 2007 11:08:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I5NVw-0001ja-6g for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2007 11:08:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I5NVt-0001in-Fx for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2007 11:08:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5NVt-0001ik-7x for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2007 11:08:29 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I5NVs-00044o-PO for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2007 11:08:28 -0400 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I5NVs-0002eK-Hv for gnu-emacs-bug@ftp.gnu.org; Mon, 02 Jul 2007 11:08:28 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1I5NVr-00044U-Hb for gnu-emacs-bug@ftp.gnu.org; Mon, 02 Jul 2007 11:08:28 -0400 Original-Received: from trinity.supernews.net ([216.168.1.22]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I5NVr-00044M-5k for gnu-emacs-bug@ftp.gnu.org; Mon, 02 Jul 2007 11:08:27 -0400 Original-Received: from pa-sjc-01.sjc-v12.supernews.net ([10.20.222.34]:59614 helo=pa-sjc-01.supernews.net) by trinity.supernews.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1I5NVn-0000kQ-5p for gnu-emacs-bug@ftp.gnu.org; Mon, 02 Jul 2007 15:08:25 +0000 Original-Received: (from news@localhost) by pa-sjc-01.supernews.net (8.13.8/8.13.8/Submit) id l62F8Mfb082929 for gnu-emacs-bug@prep.ai.mit.edu; Mon, 2 Jul 2007 15:08:22 GMT (envelope-from nntp-bounce@supernews.net) Original-Path: news.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.bug Mail-Copies-To: never User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (windows-nt) Cancel-Lock: sha1:RDsvIu06W7TtAXtKenUV1QYECMw= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 81 X-detected-kernel: FreeBSD 6.x (1) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16050 Archived-At: Eli Zaretskii writes: > Why does it make sense not to cleanup only remote files? There is no delay (or other side effect, see below) due to cleaning up local files. > How about setting recentf-auto-cleanup to a number, which will cause > the cleanup to happen when Emacs is idle for that many seconds? > That should avoid the startup delay without having the adverse > effects of keeping stale files on the list. If I set recentf-auto-cleanup that way, it will attempt a cleanup whenever emacs is idle for (say) 10 minutes. If I then touch emacs again, and let it go idle again, it will do another cleanup. The chances are excellent (I know this, because it's happened to me with other features conditioned upon "x seconds of emacs inactivity") that I will return to emacs during one of these spurts of idle-time activity. That means I'll wait for my (editor, news/mail reader, console, operating system) to become available again. Also, the delay is not the only side effect of TRAMP's promiscuity in opening a session I didn't ask for: * It causes problems when the remote system is offline or the local system is disconnected. * It leaves traces in logs on the remote system, which I may need to explain to a paranoid sysadmin (Why were you connecting to my system at 3 a.m. yesterday?) * On a modem-connected system it can cause an unwanted dial-out. If I enable the idle-time cleanup, these side effects happen every time emacs is idle for the requisite time. In my opinion, this access violates the principle of least surprise. The fact that I once opened a TRAMP connection to a system doesn't grant emacs a license to do so any other time. However, you have convinced me that my original proposal was bogus; it did not go far enough. Rather than completely avoiding cleanup of remote recentf entries, we should wait to clean them up until a new TRAMP session is opened to that host. The sticky part of this approach is drawing the line between recentf and TRAMP. I would not object to recentf knowing the difference between remote and local files, but I would rather not teach it about which files belong to which host, especially since TRAMP already knows that. So I guess the best approach would be: 0) recentf-cleanup gains an optional boolean argument REMOTE. When REMOTE is nil, recentf-cleanup igores remote files in recentf-list (i.e. it passes them through to the newlist unchanged). When REMOTE is true, it processes remote files too. 1) Whenever TRAMP opens a new session, it calls the new tramp-session-opened-hook, which calls recentf-cleanup-remote, which calls (recentf-cleanup t). 2) For remote files, recentf-expand-file-name does not call expand-file-name directly; it just calls the filename handlers. 3) TRAMP provides a filename handler called tramp-maybe-expand-file-name, which calls tramp-handle-expand-file-name only if there is already a session open to the specified host; otherwise it returns the filename unmodified. This would solve the immediate problem (in recentf-cleanup), but it does not deal with any other calls to expand-file-name that might open unwanted TRAMP sessions. To do that, one would need to identify the intent behind all expand-file-name calls in emacs, and classify them as to whether or not they should open a new TRAMP session. Seems like a lot of work, and I'm lazy. Your opinion? -- Alan Hadsell