[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find-library-name fails if file (with no extension) exists.

From: Eli Zaretskii
Subject: Re: find-library-name fails if file (with no extension) exists.
Date: Wed, 22 Nov 2006 23:56:32 +0200

> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> From: David Kastrup <address@hidden>
> Date: Wed, 22 Nov 2006 13:46:14 +0100
> > Are there any reason in those relatively simple cases that they can
> > not be solved?
> How would you do that?  Once a path component is completed, you can
> try to do an actual stat call whenever a file _appears_ not to be
> there (and I guess that this is what happens, since `/c/my documents/'
> _is_ a valid component for further completion), but an incomplete file
> name?  There is no function of the operating system for asking "is
> this a partial match with any filename"?

It looks like you never saw any real example of file-name completion
code.  Perhaps you should, because there's no problem at all to solve
this.  I even mentioned it: readdir coupled with fnmatch (which has
flags to become case-insensitive).  Of course, MS-Windows has a native
API to do this on the system call level, but that's not an important

> And I also don't see how file-truename (which presumably is used for
> collision detection) can figure out a case-corrected path without
> doing the (slow) equivalent of `/bin/pwd'.

There are a few methods, and file-truename applies one of them on
windows-nt systems, see the code; there are other methods, some of
them better.

Again, it's a non-issue if you know that you shouldn't treat file
names as simple strings.  You may think it's a very hard problem, but
it isn't.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]