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

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 11:03:42 +0100
>> 
>> > The same trouble exists with hard links.
>> 
>> No.  With a hard link you _can_ decide whether writing a file would
>> conflict with an existing file without actually doing the write by
>> looking at the existing file names in the current directory.
>
> I can do the same on Windows (and on any other case-insensitive
> filesystem).

If the file system contains a file "i.tex", will this conflict with
"İ.tex"?  If it contains "ἀ.tex", will it conflict with "Α.tex"?  Do
the conflicts change when you move from an English to a Turkish
locale?

Answer this without looking up the relevant documentation or trying it
out.  Can you?

>> >> Things like file name completion are simply something which is
>> >> impossible to get right.
>> >
>> > 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.
>
> You have a buggy port of Bash.  Get a better one.

This is the most current version of Emacs.  There is no better one.
That Bash shows the same problems is not really surprising because
there is no good way to avoid it.

>> 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?
>
> Because the code that does TRT in this case is only compiled into
> Emacs on Windows.

Likely because in a heterogenous environment there is simply no way to
get this right.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum