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

[David Kastrup <dak@gnu.org>]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>>> Really?  Then how come this has been satisfactorily solved several
>>> times already, both in Emacs and in ports of Bash?
>>
>> It has?
>>
>> So why do I get "No Match" when typing
>>
>> C-x C-f /c/my docu <TAB>
>>
>> when there is a directory
>>
>> /c/My Documents/
>>
>> and opening
>>
>> /c/my documents/test.tex
>>
>> works.  And why doesn't Emacs realize that it already has this file
>> open when I now do
>>
>> C-x C-f /c/My Documents/test.tex RET
>>
>> and opens another buffer for it?
>>
>> I don't see this as a satisfactory solution.
>
> Looks like bugs to me.

Sure.  That was my point.  Case-insensitive file systems trip up more
than just incompetently naive programmers, as people want to make
believe.  And there are no easy solutions for all problems.

> 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"?

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum