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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> 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
detail.

> 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.