Re: Inconvenience with TRAMP and recentf

[Alan Hadsell <ahadsell@mtdiablo.com>]

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