* Re: recentf-cleanup, file-readable-p & remote files
@ 2003-09-16 7:51 David PONCE
2003-09-16 7:58 ` Miles Bader
2003-09-17 2:10 ` Jesper Harder
0 siblings, 2 replies; 8+ messages in thread
From: David PONCE @ 2003-09-16 7:51 UTC (permalink / raw)
Cc: emacs-pretest-bug, emacs-devel
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 ;-)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-16 7:51 David PONCE
@ 2003-09-16 7:58 ` Miles Bader
2003-09-17 18:02 ` Richard Stallman
2003-09-17 2:10 ` Jesper Harder
1 sibling, 1 reply; 8+ messages in thread
From: Miles Bader @ 2003-09-16 7:58 UTC (permalink / raw)
Cc: harder, emacs-devel, emacs-pretest-bug
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-16 7:51 David PONCE
2003-09-16 7:58 ` Miles Bader
@ 2003-09-17 2:10 ` Jesper Harder
1 sibling, 0 replies; 8+ messages in thread
From: Jesper Harder @ 2003-09-17 2:10 UTC (permalink / raw)
Cc: emacs-pretest-bug, emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-16 7:58 ` Miles Bader
@ 2003-09-17 18:02 ` Richard Stallman
2003-09-17 20:12 ` Jesper Harder
0 siblings, 1 reply; 8+ messages in thread
From: Richard Stallman @ 2003-09-17 18:02 UTC (permalink / raw)
Cc: harder, david.ponce, emacs-pretest-bug, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-17 18:02 ` Richard Stallman
@ 2003-09-17 20:12 ` Jesper Harder
2003-09-18 15:14 ` Richard Stallman
0 siblings, 1 reply; 8+ messages in thread
From: Jesper Harder @ 2003-09-17 20:12 UTC (permalink / raw)
Cc: emacs-pretest-bug, emacs-devel
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
@ 2003-09-18 8:48 David PONCE
2003-09-19 1:45 ` Jesper Harder
0 siblings, 1 reply; 8+ messages in thread
From: David PONCE @ 2003-09-18 8:48 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-17 20:12 ` Jesper Harder
@ 2003-09-18 15:14 ` Richard Stallman
0 siblings, 0 replies; 8+ messages in thread
From: Richard Stallman @ 2003-09-18 15:14 UTC (permalink / raw)
Cc: emacs-pretest-bug, emacs-devel
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: recentf-cleanup, file-readable-p & remote files
2003-09-18 8:48 recentf-cleanup, file-readable-p & remote files David PONCE
@ 2003-09-19 1:45 ` Jesper Harder
0 siblings, 0 replies; 8+ messages in thread
From: Jesper Harder @ 2003-09-19 1:45 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-09-19 1:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-18 8:48 recentf-cleanup, file-readable-p & remote files David PONCE
2003-09-19 1:45 ` Jesper Harder
-- strict thread matches above, loose matches on Subject: below --
2003-09-16 7:51 David PONCE
2003-09-16 7:58 ` Miles Bader
2003-09-17 18:02 ` Richard Stallman
2003-09-17 20:12 ` Jesper Harder
2003-09-18 15:14 ` Richard Stallman
2003-09-17 2:10 ` Jesper Harder
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.