Re: Inconvenience with TRAMP and recentf

[Alan Hadsell <ahadsell@mtdiablo.com>]

Eli Zaretskii <eliz@gnu.org> 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