all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.