> > 3. Do #1 and perhaps rename `file-remote-p'.
>
> My quoting the docstring was specifically to explain
that we already
> solved this part of the problem by (re)defining
"remote".
OK by me.
> As for slowness, I can't remember anyone complaining
about
> file-remote-p being slow (you quoted numbers comparing
its
> speed to other code, but that doesn't make it slow).
Part of its mission is to give you a quick check, so speed
is not irrelevant.
I'm not saying it needs to be optimal, but if the more
expensive parts of the
test can be avoided by placing them last, so much the
better, no?
In any case, please let me know what you have in mind for
the patch.
I would like it to also handle Windows mapped network
drives, since their access
is a potential slowdown. But you mentioned handling also
Unix mounted drives,
and Eli mentioned that he didn't want us to include
treatment for only Windows
in this regard. And Michael has apparently already written
code for dealing with
mounts (his unpublished `file-mounted-p' code). Can we bring
together what needs
to be done for this aspect?
|