Re: recentf-cleanup, file-readable-p & remote files

Re: recentf-cleanup, file-readable-p & remote files

[David PONCE]

Hi,

> But I'm still not sure if it's not a good idea for `recentf-cleanup'
> to call `file-readable-p' on remote files _at all_.  The reason is
> that it can be a *very* slow operation.

My latest change introduced a new feature that make now possible to
have predicate functions in `recentf-exclude'.  Thus, if you add
`file-remote-p' into `recentf-exclude', remote files will no more be
put on the recent list.

More generally, I could do what you suggest and simply not call
`file-readable-p' on remote files, in `recentf-cleanup'.

However, what to do then with remote files?  Just ignore them, that is
never remove them automatically from the recent list?  Always remove
them?  Wouldn't that be equivalent of using `file-remote-p' in the
`recentf-exclude' list?

IMO a better solution would be to allow to disable connection timeout
when calling the `file-readable-p' remote handler (I don't know if
this is feasible).  So when not connected, `file-readable-p' will
immediately return nil, without waiting for a remote connection.

Thoughts?

David

P.S.: I CC  this mail to the emacs-devel ML, maybe someone here could help ;-)

Re: recentf-cleanup, file-readable-p & remote files

[Miles Bader]

David PONCE <david.ponce@wanadoo.fr> writes:
> IMO a better solution would be to allow to disable connection timeout
> when calling the `file-readable-p' remote handler (I don't know if
> this is feasible).  So when not connected, `file-readable-p' will
> immediately return nil, without waiting for a remote connection.

It makes a lot of sense for `file-readable-p' to return nil for an
unreachable file ... :-)  Maybe this should just be handled by the
appopriate remote file-handler.

-Miles
-- 
Fast, small, soon; pick any 2.

Re: recentf-cleanup, file-readable-p & remote files

[Richard Stallman]

    > IMO a better solution would be to allow to disable connection timeout
    > when calling the `file-readable-p' remote handler (I don't know if
    > this is feasible).  So when not connected, `file-readable-p' will
    > immediately return nil, without waiting for a remote connection.

    It makes a lot of sense for `file-readable-p' to return nil for an
    unreachable file ... :-)  Maybe this should just be handled by the
    appopriate remote file-handler.

What is meant by "when not connected"?
I don't understand it clearly.

Re: recentf-cleanup, file-readable-p & remote files

[Jesper Harder]

Richard Stallman <rms@gnu.org> writes:

> What is meant by "when not connected"?  I don't understand it
> clearly.

Not connected to the Internet, off-line (if you're using a telephone
modem with a per-minute charge, you're usually off-line).

Re: recentf-cleanup, file-readable-p & remote files

[Richard Stallman]

    Not connected to the Internet, off-line (if you're using a telephone
    modem with a per-minute charge, you're usually off-line).

How do you tell whether the machine is connected?

Perhaps you could call the new function network-interface-list and see
if the list contains anything except the loopback device.  That is not
entirely correct, since you might be connected to a local ethernet
which does not have an external connection, or is behind a firewall.
But is it good enough?

Re: recentf-cleanup, file-readable-p & remote files

[Jesper Harder]

David PONCE <david.ponce@wanadoo.fr> writes:

> IMO a better solution would be to allow to disable connection
> timeout when calling the `file-readable-p' remote handler (I don't
> know if this is feasible).  So when not connected, `file-readable-p'
> will immediately return nil, without waiting for a remote
> connection.

Ah, I think you misunderstood part of what I was trying to say --
which is that `file-readable-p' can be very slow when you *are*
connected (when I'm not connected it returns in a fraction of second,
so that's not a problem)

The reason is that that ange-ftp implements it rather inefficiently.
Instead of just listing the file in question it lists *all* files in
the directory.  That's a lot of data if the directory contains
thousands of files.  In the example from my previous post doing
`file-readable-p' is ~500 times slower than actually fetching the
file!

-- 
Cheers,
Jesper Harder

Re: recentf-cleanup, file-readable-p & remote files

[David PONCE]

Hi,

> Ah, I think you misunderstood part of what I was trying to say --
> which is that `file-readable-p' can be very slow when you *are*
> connected (when I'm not connected it returns in a fraction of second,
> so that's not a problem)
>
> The reason is that that ange-ftp implements it rather inefficiently.
> Instead of just listing the file in question it lists *all* files in
> the directory.  That's a lot of data if the directory contains
> thousands of files.  In the example from my previous post doing
> `file-readable-p' is ~500 times slower than actually fetching the
> file!

OK, thank you for the explanation, I understand better now!

Could you try file-exists-p please?  Does it work better?

A possibility could be to consider that remote files are always
readable and change `recentf-file-readable-p' like this:

(defsubst recentf-file-readable-p (filename)
  "Return t if file FILENAME exists and you can read it.
Assume that remote files are always readable."
  (or (file-remote-p filename)
      (file-readable-p filename)))

Remote files then could be manually removed from the recent list (M-x
recentf-edit-list), or will be removed naturally by the LRU mechanism
if they are not accessed for a long time (see the option
`recentf-max-saved-items').

Perhaps, in your case, another acceptable workaround could be to
disable the `recentf-auto-cleanup' feature (customize this option to
`never'), and let the LRU mechanism eliminate files not accessed for a
long time.

Thoughts?

David

Re: recentf-cleanup, file-readable-p & remote files

[Jesper Harder]

David PONCE <david.ponce@wanadoo.fr> writes:

>> In the example from my previous post doing `file-readable-p' is
>> ~500 times slower than actually fetching the file!
>
> Could you try file-exists-p please?  Does it work better?

No, it works the same way.

> A possibility could be to consider that remote files are always
> readable and change `recentf-file-readable-p' like this:
>
>   (or (file-remote-p filename)
>       (file-readable-p filename)))
>
> Remote files then could be manually removed from the recent list (M-x
> recentf-edit-list), or will be removed naturally by the LRU mechanism

Sounds good to me.

> Perhaps, in your case, another acceptable workaround could be to
> disable the `recentf-auto-cleanup' feature (customize this option to
> `never')

Your previous suggestion about adding `file-remote-p' to
`recentf-exclude' works fine for me personally.

I was thinking more about whether the side effects of the default
setting are desirable -- i.e. that turning on recentf might initiate a
multi-megabyte download of a directory listing.