Inconvenience with TRAMP and recentf

Inconvenience with TRAMP and recentf

[Alan Hadsell]

I'm running emacs 22.1 on Windows, and have recentf turned on.  If
recentf-auto-cleanup is configured with its default, there is a delay
during emacs startup when there are TRAMP-accessed files in the recent
file list.  

This delay is due to the operation of recentf-cleanup, which calls
expand-file-name to canonicalize the names of all the files in its
list.  TRAMP intercepts this call, and opens a session to the remote
host (unless one is already open).  

There are several workarounds for this problem: I can reconfigure
recentf-auto-cleanup to 'never, or exclude TRAMP files from the
recentf list; neither of these approaches is really appealing.  I'm
sure there are other ways, too.

I was thinking to add a boolean recentf-cleanup-local-files-only,
which would allow us to avoid trying to do cleanup for TRAMP files.
Before I go away to hack on that solution, does anyone have a better
idea?

-- 
Alan Hadsell

Re: Inconvenience with TRAMP and recentf

[Eli Zaretskii]

> From: Alan Hadsell <ahadsell@mtdiablo.com>
> Date: Sun, 01 Jul 2007 18:15:11 -0400
> Cc: 
> 
> There are several workarounds for this problem: I can reconfigure
> recentf-auto-cleanup to 'never, or exclude TRAMP files from the
> recentf list; neither of these approaches is really appealing.  I'm
> sure there are other ways, too.
> 
> I was thinking to add a boolean recentf-cleanup-local-files-only,
> which would allow us to avoid trying to do cleanup for TRAMP files.

Why does it make sense not to cleanup only remote files?

> Before I go away to hack on that solution, does anyone have a better
> idea?

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.

Re: Inconvenience with TRAMP and recentf

[Michael Albinus]

Alan Hadsell <ahadsell@mtdiablo.com> writes:

> I'm running emacs 22.1 on Windows, and have recentf turned on.  If
> recentf-auto-cleanup is configured with its default, there is a delay
> during emacs startup when there are TRAMP-accessed files in the recent
> file list.  
>
> This delay is due to the operation of recentf-cleanup, which calls
> expand-file-name to canonicalize the names of all the files in its
> list.  TRAMP intercepts this call, and opens a session to the remote
> host (unless one is already open).  

In expand-file-name, Tramp needs to open a remote connection only in
case the local file name is not absolute, and it must expand the home
directory to an absolute file name.

So the file names in ~/.recentf shall be saved with an absolute local
file name. Then you could add file-remote-p to recentf-keep, as it is
proposed in the doc-string of recentf-keep.

Best regards, Michael.

Re: Inconvenience with TRAMP and recentf

[Alan Hadsell]

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

Re: Inconvenience with TRAMP and recentf

[Alan Hadsell]

Michael Albinus <michael.albinus@gmx.de> writes:

> In expand-file-name, Tramp needs to open a remote connection only in
> case the local file name is not absolute, and it must expand the home
> directory to an absolute file name.

In my case, the entries in my recentf-list are already absolute:
e.g. /pscp:al@fibonacci.pacengr.com:/home/al/delete_data.sql.  But
TRAMP still opens a new session whenever I start emacs.

Incidentally, maybe it would be a good idea to canonicalize the remote
filenames when they are first placed in the recentf-list, rather than
waiting for recentf-cleanup to do it.

> So the file names in ~/.recentf shall be saved with an absolute local
> file name. Then you could add file-remote-p to recentf-keep, as it is
> proposed in the doc-string of recentf-keep.

Unfortunately, that does not bypass the call to expand-file-name in
recentf-expand-file-name, which is called from recentf-cleanup before
the "keep" determination is made.  It is the call to expand-file-name
that causes the remote session to be opened.

-- 
Alan Hadsell

Re: Inconvenience with TRAMP and recentf

[Michael Albinus]

Alan Hadsell <ahadsell@mtdiablo.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> In expand-file-name, Tramp needs to open a remote connection only in
>> case the local file name is not absolute, and it must expand the home
>> directory to an absolute file name.
>
> In my case, the entries in my recentf-list are already absolute:
> e.g. /pscp:al@fibonacci.pacengr.com:/home/al/delete_data.sql.  But
> TRAMP still opens a new session whenever I start emacs.

I did test it locally (Emacs 22.1.50.2, Tramp 2.0.56). If the remote
file name in .recentf contains already an absolute local file name,
expand-file-name does NOT open a connection. The connection is opened by
file-readable-p.

The remote connection is NOT opened with the following settings in my
.emacs:

(require 'recentf)
(add-to-list 'recentf-keep 'file-remote-p)
(recentf-mode 1)

> Incidentally, maybe it would be a good idea to canonicalize the remote
> filenames when they are first placed in the recentf-list, rather than
> waiting for recentf-cleanup to do it.

Yes. But it seems all file names in .recentf are already absolute; at
least according to my tests. So the settings above might be sufficient,
aren't they?

Best regards, Michael.

Re: Inconvenience with TRAMP and recentf

[Alan Hadsell]

Michael Albinus <michael.albinus@gmx.de> writes:

> I did test it locally (Emacs 22.1.50.2, Tramp 2.0.56). If the remote
> file name in .recentf contains already an absolute local file name,
> expand-file-name does NOT open a connection. The connection is opened by
> file-readable-p.
>
> The remote connection is NOT opened with the following settings in my
> .emacs:
>
> (require 'recentf)
> (add-to-list 'recentf-keep 'file-remote-p)
> (recentf-mode 1)

You're right.  That works.  Clearly I missed something when I was
reviewing  the code; I'll have to re-read it.

>> Incidentally, maybe it would be a good idea to canonicalize the remote
>> filenames when they are first placed in the recentf-list, rather than
>> waiting for recentf-cleanup to do it.
>
> Yes. But it seems all file names in .recentf are already absolute; at
> least according to my tests. So the settings above might be sufficient,
> aren't they?

Yes, they show up in absolute format in .recentf, which is what
matters for this purpose.  I was fooled by the fact that they
initially show up in relative format in the recentf menu, and only
change to absolute format when emacs is restarted.

So the only problem with this approach is that a remote file that
disappears or becomes unreadable will not be removed from the recent
file list until it falls off the end.  I proposed an alternative
solution in another branch of this thread, but it was baroque and
tricky.

I suppose one could construct another predicate for the recentf-keep
list.  Rather than file-remote-p, one could use
tramp-remote-host-offline-p, which would return true if the file name
was remote and there was no session open to the remote host.  That
would allow the normal file-readable-p test to be performed if the
remote host was already online, but would not create a new session if
it was not.  Maybe I'll try this approach if I get sufficient tuits.

Thanks for your help.

-- 
Alan Hadsell