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

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

[Juanma Barranquero]

This change from one year ago has an unintended side effect: Emacs
finds the wrong file if a file exists in the path with the same name
and no extension, though the link pointed explicitly to the .el file.

2005-10-25  Romain Francoise  <romain@orebokech.com>

        * emacs-lisp/find-func.el (find-library-name): Also strip
        extension if library name ends in .el, to take advantage of
        `find-library-suffixes'.

My case: I have nxml-mode installed on site-lisp, and it contains a
file named "VERSION". If I do "M-x describe-variable emacs-version
RET", move onto the "version.el" link and hit enter, Emacs finds
"VERSION" and complains "Unable to find location in file".

I can understand

  (find-library-name "version") => /my/site-lips/VERSION

but

  (find-library-name "version.el") => /my/site-lisp/VERSION

is beyond weird.

                    /L/e/k/t/u

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

[Romain Francoise]

This change is necessary to find the "foo.el.gz" file if `symbol-file'
returns that the definition is in "foo.el" -- since we compress source
files after installing them (on systems where gzip is present), trying
to find a file named foo.el will fail.

Note that the same problem existed before my change with files ending in
".elc".

I'm not sure if this is worth fixing before the release, this code is
very convoluted and there are quite a few corner cases.  For example, if
you start Emacs with `emacs -Q', then do `C-h f erc RET', it says

  erc is an interactive autoloaded Lisp function in `erc'.
                                                    ^^^^^
Then if you M-: (require 'erc) RET and try again, it says

  erc is an interactive compiled Lisp function in `erc.el'.
                                                  ^^^^^^^^
This is because in the first case the filename is fetched from the
autoloads, and in the second case it's fetched from `load-history'.
So trying to generalize a method is tricky: it must work with "erc"
and "erc.el".

If it's any consolation, the bug you're describing doesn't happen on a
real system, where the filesystem is case-sensitive.  ;-)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

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

[Juanma Barranquero]

On 11/21/06, Romain Francoise <romain@orebokech.com> wrote:

> This change is necessary to find the "foo.el.gz" file if `symbol-file'
> returns that the definition is in "foo.el" -- since we compress source
> files after installing them (on systems where gzip is present), trying
> to find a file named foo.el will fail.

I know that, but:

> For example, if
> you start Emacs with `emacs -Q', then do `C-h f erc RET', it says
>
>   erc is an interactive autoloaded Lisp function in `erc'.
>                                                     ^^^^^
> Then if you M-: (require 'erc) RET and try again, it says
>
>   erc is an interactive compiled Lisp function in `erc.el'.

That seems sensible. find-library-name's goal is to find an elisp
library. Those are not usually found in files without a prefix.

In other words: when looking for "erc", trying "erc.el" and
"erc.el.gz" seem sensible. When looking for "erc.el", trying "erc.el"
and "erc.el.gz" is still sensible; but to try "erc" is absurd. No,
scratch that: it is a bug :)

> If it's any consolation, the bug you're describing doesn't happen on a
> real system, where the filesystem is case-sensitive.  ;-)

Ha, ha. Case-sensitive filesystems make the same sense that
case-sensitive languages: none at all. (Note that Common Lisp is
case-insensitive.)

                    /L/e/k/t/u

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

[Romain Francoise]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> In other words: when looking for "erc", trying "erc.el" and
> "erc.el.gz" seem sensible. When looking for "erc.el", trying "erc.el"
> and "erc.el.gz" is still sensible; but to try "erc" is absurd. No,
> scratch that: it is a bug :)

Right.

I see now that this change:

2006-02-26  Luc Teirlinck  <teirllm@auburn.edu>

	* emacs-lisp/find-func.el (find-library-name):
	Use `load-file-rep-suffixes' instead of '("").

added ".gz" to the suffixes.

So "foo.el.gz" will be found even when looking for "foo.el".
In other words, my change can be reverted, so I've now done that.

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

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

[Juanma Barranquero]

On 11/21/06, Romain Francoise <romain@orebokech.com> wrote:

> So "foo.el.gz" will be found even when looking for "foo.el".
> In other words, my change can be reverted, so I've now done that.

I don't think is right yet:

ELISP> (find-library-name "desktop.el")
"c:/emacs/HEAD/lisp/desktop.el"
ELISP> (find-library-name "desktop.elc")
"c:/emacs/HEAD/lisp/desktop.el"
ELISP> (find-library-name "version.el")
"c:/emacs/HEAD/lisp/version.el"
ELISP> (find-library-name "version.elc")
"c:/emacs/site-lisp/nxml-mode/version"
ELISP>

                    /L/e/k/t/u

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

[Romain Francoise]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> I don't think is right yet:
> ELISP> (find-library-name "version.elc")
> "c:/emacs/site-lisp/nxml-mode/version"

As noted in <8764d8u085.fsf@pacem.orebokech.com>:

    Note that the same problem existed before my change with files
    ending in ".elc".

This problem is still there, since I just reverted my change.

But frankly, I doubt it'll bother anyone.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

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

[Juanma Barranquero]

On 11/22/06, Romain Francoise <romain@orebokech.com> wrote:

> As noted in <8764d8u085.fsf@pacem.orebokech.com>:
>
>     Note that the same problem existed before my change with files
>     ending in ".elc".
>
> This problem is still there, since I just reverted my change.
>
> But frankly, I doubt it'll bother anyone.

This simple patch does fix the problem. Am I overlooking something
obvious? (The patch is really one-line; the change in the regexp is
just to remove leftover parentheses.)

                    /L/e/k/t/u



Index: lisp/emacs-lisp/find-func.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/find-func.el,v
retrieving revision 1.78
diff -u -2 -r1.78 find-func.el
--- lisp/emacs-lisp/find-func.el	21 Nov 2006 20:06:53 -0000	1.78
+++ lisp/emacs-lisp/find-func.el	22 Nov 2006 12:05:07 -0000
@@ -150,6 +150,6 @@
   ;; If the library is byte-compiled, try to find a source library by
   ;; the same name.
-  (if (string-match "\\.el\\(c\\(\\..*\\)?\\)\\'" library)
-      (setq library (replace-match "" t t library)))
+  (if (string-match "\\.elc\\(\\..*\\)?\\'" library)
+      (setq library (replace-match ".el" t t library)))
   (or (locate-file library
 		   (or find-function-source-path load-path)

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

[Juanma Barranquero]

On 11/22/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> This simple patch does fix the problem.

This one makes even more sense, because library is not modified, so
the error message still refers to the library passed to the func.

                    /L/e/k/t/u


Index: lisp/emacs-lisp/find-func.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/find-func.el,v
retrieving revision 1.78
diff -u -2 -r1.78 find-func.el
--- lisp/emacs-lisp/find-func.el	21 Nov 2006 20:06:53 -0000	1.78
+++ lisp/emacs-lisp/find-func.el	22 Nov 2006 12:29:12 -0000
@@ -150,7 +150,6 @@
   ;; If the library is byte-compiled, try to find a source library by
   ;; the same name.
-  (if (string-match "\\.el\\(c\\(\\..*\\)?\\)\\'" library)
-      (setq library (replace-match "" t t library)))
-  (or (locate-file library
+  (or (locate-file (replace-regexp-in-string "\\.elc\\(\\..*\\)?\\'" ".el"
+					     library t t)
 		   (or find-function-source-path load-path)
 		   (append (find-library-suffixes) load-file-rep-suffixes))

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

[Romain Francoise]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Am I overlooking something obvious?

Yes, the fact that the source of a compiled Lisp file doesn't
necessarily end with ".el".  For example, if you compile a source
file named ~/.emacs, the compiled file is named ~/.emacs.elc.

This is why this function first strips ".elc", then tries to find the
file with a list of suffixes that includes the empty string.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

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

[Juanma Barranquero]

(I accidentally took this off-list)

On 11/22/06, Romain Francoise <romain@orebokech.com> wrote:

> Yes, the fact that the source of a compiled Lisp file doesn't
> necessarily end with ".el".  For example, if you compile a source
> file named ~/.emacs, the compiled file is named ~/.emacs.elc.

You're right (though I'd like to know if that's much used outside the
corner ~/.emacs case).

The current behavior, then, has the problem that compiling files with
no extension, or non-default ones:

  mylib => mylib.elc
  mylib.dat => mylib.dat.elc

but help from describe-function and friends points to nonexistent
"mylib.el" and "mylib.dat.el".

                    /L/e/k/t/u

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

[Romain Francoise]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> The current behavior, then, has the problem that compiling files with
> no extension, or non-default ones:

>  mylib => mylib.elc
>  mylib.dat => mylib.dat.elc

> but help from describe-function and friends points to nonexistent
> "mylib.el" and "mylib.dat.el".

Yes, because of `describe-simplify-lib-file-name'...

The reliable approach would be to look into the compiled file, it
contains the source file's name.  But it would be overkill.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

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

[Lennart Borgman]

Romain Francoise wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
>> The current behavior, then, has the problem that compiling files with
>> no extension, or non-default ones:
> 
>>  mylib => mylib.elc
>>  mylib.dat => mylib.dat.elc
> 
>> but help from describe-function and friends points to nonexistent
>> "mylib.el" and "mylib.dat.el".
> 
> Yes, because of `describe-simplify-lib-file-name'...
> 
> The reliable approach would be to look into the compiled file, it
> contains the source file's name.  But it would be overkill.

Maybe look into the compiled file if the first-guess source file does 
not exist?

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

[Juanma Barranquero]

On 11/22/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Maybe look into the compiled file if the first-guess source file does
> not exist?

Why particularize on the first guess? Removing the extension and
trying .el, .el.gz, etc. is a game of musical chairs. Better to follow
the safe route.

But this is for after the release, I think.

                    /L/e/k/t/u

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

[Eli Zaretskii]

> Date: Tue, 21 Nov 2006 20:09:59 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> When looking for "erc.el", trying "erc.el" and "erc.el.gz" is still
> sensible; but to try "erc" is absurd. No, scratch that: it is a bug :)

I agree.  I suggest that we try to fix this before the release.

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

[Andreas Schwab]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> Ha, ha. Case-sensitive filesystems make the same sense that
> case-sensitive languages: none at all. (Note that Common Lisp is
> case-insensitive.)

Languages are case-sensistive by nature.  There is a big difference
between paar and Paar in German.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

Andreas Schwab wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
>> Ha, ha. Case-sensitive filesystems make the same sense that
>> case-sensitive languages: none at all. (Note that Common Lisp is
>> case-insensitive.)
> 
> Languages are case-sensistive by nature.  There is a big difference
> between paar and Paar in German.


That is a nice point. I have always thought there is a big difference 
between "woff" and "WOFF".

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

[Juanma Barranquero]

On 11/21/06, Andreas Schwab <schwab@suse.de> wrote:

> Languages are case-sensistive by nature.

Writing systems are. Sometimes (there are languages where the
difference does not exist; think classical latin). But most people is
able to talk a language without pausing to signal whether the next
word is capitalized or not.

                    /L/e/k/t/u

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

[Juanma Barranquero]

On 11/21/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> > Languages are case-sensistive by nature.

Not to mention that I was speaking of *programming* languages, of course :)

                    /L/e/k/t/u

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

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/21/06, Andreas Schwab <schwab@suse.de> wrote:
>
>> Languages are case-sensistive by nature.
>
> Writing systems are. Sometimes (there are languages where the
> difference does not exist; think classical latin).

But nevertheless nobody would think of proposing that voluntas.tex and
volvntas.tex should map to the same file.

Having different file names map to the same file is a recipe for
trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Juanma Barranquero]

On 11/21/06, David Kastrup <dak@gnu.org> wrote:

> But nevertheless nobody would think of proposing that voluntas.tex and
> volvntas.tex should map to the same file.

Not today. Every single roman (from the classical period) able to read
and use a computer would have proposed just that!

> Having different file names map to the same file is a recipe for
> trouble.

Circular reasoning. MyBook.txt and mybook.txt are not different file
names in case-insensitive systems. Certainly, when I'm looking for
that old picture of my dogs, I want to find "Mila&Nero.png" when I
search for "mila&nero". I don't distinguish between capitalized or
non-capitalized words, except in very specific (written) contexts. I
don't know why my computer should insist I do.

And plenty of successful operating systems have been case-insensitive,
so it is clearly not a bad idea, not unworkable, nor particularly
dangerous, difficult to implement, or hard on the user. It's just
another UI decision. One I like a lot.

                    /L/e/k/t/u

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

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/21/06, David Kastrup <dak@gnu.org> wrote:
>
>> But nevertheless nobody would think of proposing that voluntas.tex and
>> volvntas.tex should map to the same file.
>
> Not today. Every single roman (from the classical period) able to read
> and use a computer would have proposed just that!
>
>> Having different file names map to the same file is a recipe for
>> trouble.
>
> Circular reasoning. MyBook.txt and mybook.txt are not different file
> names in case-insensitive systems.

Yes, they are.  As can easily be verified by listing the directory
after creating either file.

They certainly _are_ different file names, but they can't refer to
different files.

> Certainly, when I'm looking for that old picture of my dogs, I want
> to find "Mila&Nero.png" when I search for "mila&nero".

That does not make the names the same, merely changes your search
strategy.

> I don't distinguish between capitalized or non-capitalized words,
> except in very specific (written) contexts. I don't know why my
> computer should insist I do.

It doesn't.  It just insists that you are consistent.  If you want to
write lowercase, do so.  If you want to capitalize, do so.

> And plenty of successful operating systems have been
> case-insensitive, so it is clearly not a bad idea, not unworkable,

It is a constant source for trouble in scripts of all sorts.  I guess
about 20% of Windows installation problem reports with AUCTeX
originate from capitalization mixups.

> nor particularly dangerous, difficult to implement, or hard on the
> user. It's just another UI decision. One I like a lot.

It is a constant trouble for programmers, and that leads to quite
obtuse user problems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Lennart Borgman]

David Kastrup wrote:

> It is a constant trouble for programmers, and that leads to quite
> obtuse user problems.

The trouble is that it is easy to forgot the other alternative (case 
sensiteve/insensitive file names) when you write code. None of the 
alternatives is a trouble per se.

And yes, it is a very irritating problem.

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

[David Kastrup]

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

> David Kastrup wrote:
>
>> It is a constant trouble for programmers, and that leads to quite
>> obtuse user problems.
>
> The trouble is that it is easy to forgot the other alternative (case
> sensiteve/insensitive file names) when you write code.

It is not even possible to write code with a reasonable chance of
working reliably since one can have Windows and Unix file systems on
the same system and export either with Samba or NFS or a number of
other ways.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Juanma Barranquero]

On 11/22/06, David Kastrup <dak@gnu.org> wrote:

> It is not even possible to write code with a reasonable chance of
> working reliably since one can have Windows and Unix file systems on
> the same system and export either with Samba or NFS or a number of
> other ways.

And this is the fault of Windows because... Ah, yes, because!

                    /L/e/k/t/u

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

[Lennart Borgman]

David Kastrup wrote:

> It is not even possible to write code with a reasonable chance of
> working reliably since one can have Windows and Unix file systems on
> the same system and export either with Samba or NFS or a number of
> other ways.

If (a very big IF perhaps) Samba, NFS etc preserves the case of file 
names in each export and the software is written with the possibility of 
both case sensitive and case insensitive file systems in mind it seems 
possible to me.

Or am I missing something there?

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

[David Kastrup]

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

> David Kastrup wrote:
>
>> It is not even possible to write code with a reasonable chance of
>> working reliably since one can have Windows and Unix file systems on
>> the same system and export either with Samba or NFS or a number of
>> other ways.
>
> If (a very big IF perhaps) Samba, NFS etc preserves the case of file
> names in each export and the software is written with the possibility
> of both case sensitive and case insensitive file systems in mind it
> seems possible to me.
>
> Or am I missing something there?

You can't decide that two file names might indicate the same file
without doing an actual file operation.  You can't decide whether
writing a file would conflict with an existing file without actually
doing the write (and asking the operating system to fail in case the
file exists).  You can't really base any decision on existing file
names.  As a rule of thumb, if there is a possibility for a race
condition, there is a possibility for filename aliasing trouble.  And
not every potential race condition is a problem.

Things like file name completion are simply something which is
impossible to get right.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> David Kastrup wrote:
>>
>>> It is not even possible to write code with a reasonable chance of
>>> working reliably since one can have Windows and Unix file systems on
>>> the same system and export either with Samba or NFS or a number of
>>> other ways.
>> If (a very big IF perhaps) Samba, NFS etc preserves the case of file
>> names in each export and the software is written with the possibility
>> of both case sensitive and case insensitive file systems in mind it
>> seems possible to me.
>>
>> Or am I missing something there?
> 
> You can't decide that two file names might indicate the same file
> without doing an actual file operation.  You can't decide whether
> writing a file would conflict with an existing file without actually
> doing the write (and asking the operating system to fail in case the
> file exists).  You can't really base any decision on existing file
> names.  As a rule of thumb, if there is a possibility for a race
> condition, there is a possibility for filename aliasing trouble.  And
> not every potential race condition is a problem.
> 
> Things like file name completion are simply something which is
> impossible to get right.


But does not that depend on the use of file names? If file names are 
choosen so that they work on both case insensitive and case sensitive 
system are there then any problems? At least that has been the problem 
in the cases I have seen. Most often the problem has actually been that 
someone writing on a case sensitive file system forgot to take care of 
this. (That is of course an easy mistake to make.)

I am aware of the cases you mentioned to Juanma where there really are 
no way to do lowercase/uppercase certain letters. Could not they be 
handled (and are they not already handled) as different letters even 
though they outside the computer world may look at uppercase/lowercase 
variants of the same letter?

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

[David Kastrup]

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

> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>> David Kastrup wrote:
>>>
>>>> It is not even possible to write code with a reasonable chance of
>>>> working reliably since one can have Windows and Unix file systems on
>>>> the same system and export either with Samba or NFS or a number of
>>>> other ways.
>>> If (a very big IF perhaps) Samba, NFS etc preserves the case of file
>>> names in each export and the software is written with the possibility
>>> of both case sensitive and case insensitive file systems in mind it
>>> seems possible to me.
>>>
>>> Or am I missing something there?
>>
>> You can't decide that two file names might indicate the same file
>> without doing an actual file operation.  You can't decide whether
>> writing a file would conflict with an existing file without
>> actually doing the write (and asking the operating system to fail
>> in case the file exists).  You can't really base any decision on
>> existing file names.  As a rule of thumb, if there is a possibility
>> for a race condition, there is a possibility for filename aliasing
>> trouble.  And not every potential race condition is a problem.
>>
>> Things like file name completion are simply something which is
>> impossible to get right.
>
> But does not that depend on the use of file names? If file names are
> choosen so that they work on both case insensitive and case
> sensitive system are there then any problems?

If you use only lowercase filenames (for some reasonable definition of
lowercase), you'll not run into trouble.  But the whole point of case
insensitity is to encourage using mixed case filenames.

> At least that has been the problem in the cases I have seen. Most
> often the problem has actually been that someone writing on a case
> sensitive file system forgot to take care of this. (That is of
> course an easy mistake to make.)

How are you going to figure out whether a given directory is in
load-path?

> I am aware of the cases you mentioned to Juanma where there really
> are no way to do lowercase/uppercase certain letters. Could not they
> be handled (and are they not already handled) as different letters
> even though they outside the computer world may look at
> uppercase/lowercase variants of the same letter?

The problem is that "case sensitivity" requires a notion of "identical
except for case", and it is hardly to be expected that every
application has string manipulation functions that will have exactly
the same idea concerning "identical except for case" as the operating
system will have with regard to file names, in particular once we are
leaving the area of 7-bit ASCII.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Lennart Borgman]

David Kastrup wrote:

> If you use only lowercase filenames (for some reasonable definition of
> lowercase), you'll not run into trouble.  But the whole point of case
> insensitity is to encourage using mixed case filenames.

But don't you have to distinguish between the user and the programmer 
here? As a programmer you may handle this. If the user is not aware of 
the problem you can not stop him/her from doing wrong - of course.


> How are you going to figure out whether a given directory is in
> load-path?

Sorry, I do not understand. Can you be more concrete?

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

[David Kastrup]

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

> David Kastrup wrote:
>
>> If you use only lowercase filenames (for some reasonable definition of
>> lowercase), you'll not run into trouble.  But the whole point of case
>> insensitity is to encourage using mixed case filenames.
>
> But don't you have to distinguish between the user and the
> programmer here? As a programmer you may handle this.

I fail to see how this can be handled reasonably by a programmer.  How
do I deal with a case insensitive file system (fat32 or Samba share)
with a mount point in a case sensitive file system?

> If the user is not aware of the problem you can not stop him/her
> from doing wrong - of course.
>
>> How are you going to figure out whether a given directory is in
>> load-path?
>
> Sorry, I do not understand. Can you be more concrete?

The user (or a configure script or whatever) specifies a directory.
How can an Elisp program figure out whether this directory is present
in load-path?  This is the sort of trouble that the configuration
scripts in AUCTeX run into.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 02:04:58 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
> 
> The problem is that "case sensitivity" requires a notion of "identical
> except for case"

Only if you use string comparison for comparing file names.  File
names are not strings for the purpose of equality, as Juanma pointed
out, and programmers should be educated to think that way.  Just
change your abstraction, and you are done.  For example, there's a
different function, even in the string class, for ``identical but for
case'' comparison.

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

[Juanma Barranquero]

On 11/22/06, Eli Zaretskii <eliz@gnu.org> wrote:

> Only if you use string comparison for comparing file names.  File
> names are not strings for the purpose of equality, as Juanma pointed
> out, and programmers should be educated to think that way.  Just
> change your abstraction, and you are done.

This nicely summarizes all the discussion. Thanks.

                    /L/e/k/t/u

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 02:04:58 +0100
>> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
>> 
>> The problem is that "case sensitivity" requires a notion of "identical
>> except for case"
>
> Only if you use string comparison for comparing file names.  File
> names are not strings for the purpose of equality, as Juanma pointed
> out, and programmers should be educated to think that way.  Just
> change your abstraction, and you are done.  For example, there's a
> different function, even in the string class, for ``identical but for
> case'' comparison.

Where is the guarantee that this function delivers identical results
to the operating system?  Where is the hash function that makes
dealing with directory listings natural?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 11:05:23 +0100
> 
> Where is the guarantee that this function delivers identical results
> to the operating system?

That's why it's called ``system call''.

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 01:47:53 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
> 
> You can't decide that two file names might indicate the same file
> without doing an actual file operation.  You can't decide whether
> writing a file would conflict with an existing file without actually
> doing the write (and asking the operating system to fail in case the
> file exists).  You can't really base any decision on existing file
> names.  As a rule of thumb, if there is a possibility for a race
> condition, there is a possibility for filename aliasing trouble.  And
> not every potential race condition is a problem.

The same trouble exists with hard links.

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

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 01:47:53 +0100
>> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
>> 
>> You can't decide that two file names might indicate the same file
>> without doing an actual file operation.  You can't decide whether
>> writing a file would conflict with an existing file without actually
>> doing the write (and asking the operating system to fail in case the
>> file exists).  You can't really base any decision on existing file
>> names.  As a rule of thumb, if there is a possibility for a race
>> condition, there is a possibility for filename aliasing trouble.  And
>> not every potential race condition is a problem.
>
> 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.

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Lennart Borgman]

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. Are there any reason in those relatively simple 
cases that they can not be solved?

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

[David Kastrup]

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

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

[Eli Zaretskii]

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

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

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

Considering that
/c/my programs/
is the same directory as
/c/My Programs/
but
/C/My Programs/
does not exist, and
/media/usbdisk/My Programs/
may or may not be identical to
/media/usbdisk/my programs/
depending on the file system with which the stick is formatted,
and considering that fnmatch does not actually look at the file
systems to determine whether they are case insensitive or not and the
sensitivity depends on what is currently mounted where and is
different in different components of a file path, [deep breath]
I think you are misrepresenting how easy everything is.

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

I'll cede that point once you fixed this in Emacs.  Should not be very
hard.

Good luck.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 23:06:26 +0100
> 
> Considering that
> /c/my programs/
> is the same directory as
> /c/My Programs/
> but
> /C/My Programs/
> does not exist, and
> /media/usbdisk/My Programs/
> may or may not be identical to
> /media/usbdisk/my programs/
> depending on the file system with which the stick is formatted,
> and considering that fnmatch does not actually look at the file
> systems to determine whether they are case insensitive or not and the
> sensitivity depends on what is currently mounted where and is
> different in different components of a file path, [deep breath]
> I think you are misrepresenting how easy everything is.

Considering that I've solved this problem more than once, and saw
others do it with at least the same success, I think you see problems
where there are none.

> > 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.
> 
> I'll cede that point once you fixed this in Emacs.  Should not be very
> hard.

It's already solved, in the w32 parts of the code.  If it will ever be
decided that Posix platforms want to behave case-insensitively on
case-insensitive filesystems (I don't expect such a decision any time
soon), it should be easy to port that code to the other platforms.

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

[Jan Djärv]

Eli Zaretskii skrev:

>>> 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.
>> I'll cede that point once you fixed this in Emacs.  Should not be very
>> hard.
> 
> It's already solved, in the w32 parts of the code.  If it will ever be
> decided that Posix platforms want to behave case-insensitively on
> case-insensitive filesystems (I don't expect such a decision any time
> soon), it should be easy to port that code to the other platforms.

Do you mean Emacs behaves correctly on w32 when reading from an ext2 (case
sensitive file system) mount?  I must try that again then.

	Jan D.

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

[Eli Zaretskii]

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

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

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

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

[David Kastrup]

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

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 20:13:15 +0100
> 
> 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?

Sure, I can: call the right interface, and it will tell you.  I already
explained twice how to do that, I won't explain for the 3rd time.

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

On what OS?  If it's a Posix build or a Cygwin port on Windows, then
it's no surprise that it doesn't DTRT, since the code to handle this
properly isn't compiled in.

In the native Windows build, this all works as expected: completion
finds the file in the right letter-case (i.e. "C-x C-f my docu TAB"
shows "My Documents"), and visiting a file which already has a buffer
visiting its other letter-case variant does not produce a new buffer.

> That Bash shows the same problems is not really surprising because
> there is no good way to avoid it.

Your keeping saying that doesn't make it a fact.

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

Of course, there is: the behavior should be different on different
kinds of filesystems.

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 00:33:45 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
> 
> It is not even possible to write code with a reasonable chance of
> working reliably since one can have Windows and Unix file systems on
> the same system and export either with Samba or NFS or a number of
> other ways.

There is such a way: don't ``forget'' that letter-case cannot always
be distinguished in file names.

In other words, this sub-thread goes nowhere.  It's clear that you
dislike case-insensitivity in file names, and you are not alone.  It's
also very clear that the other opinion has its proponents, too, who
are not exactly morons.  So let's leave it at that; we don't have to
agree.

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

[Juanma Barranquero]

On 11/22/06, David Kastrup <dak@gnu.org> wrote:

> Yes, they are.  As can easily be verified by listing the directory
> after creating either file.

Not so. I create MyBook.txt. I "dir mybook.txt". I got the same file.
Just one filename. Don't try to impose your Unix worldview on me!

> They certainly _are_ different file names, but they can't refer to
> different files.

They certainly are *not*, in a case-insensitive filesystem.

> That does not make the names the same, merely changes your search
> strategy.

You're overlooking what I said: that *I* don't distinguish between
Mila&Nero and mila&nero (unless writing a message like this one), so
my computer should not try to force me into doing it.

> It doesn't.  It just insists that you are consistent.  If you want to
> write lowercase, do so.  If you want to capitalize, do so.

I *am* consistent: I consistently refuse to think that Mila&Nero and
mila&nero could meaningfully refer to different entities. Certainly, I
do answer e-mails to me even when they start with "dear juanma".

> It is a constant source for trouble in scripts of all sorts.

As Lennart said: it is, with scripts written from the case-sensitive
mindset. That's not fault of the other alternative. I've never had
trouble with capitalization on VMS, OS/2, CP/M, DOS, Windows, Oasis,
THEOS and other case-insensitive systems.

                    /L/e/k/t/u

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

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/22/06, David Kastrup <dak@gnu.org> wrote:
>
>> Yes, they are.  As can easily be verified by listing the directory
>> after creating either file.
>
> Not so. I create MyBook.txt. I "dir mybook.txt". I got the same
> file.

Listing the directory.  Just
dir
and nothing else.

> Just one filename. Don't try to impose your Unix worldview on me!

It is your Windows system that throws the file name with the same
capitalization with which it was created back at you.

So yes, the file name preserves capitalization.

>> They certainly _are_ different file names, but they can't refer to
>> different files.
>
> They certainly are *not*, in a case-insensitive filesystem.

List the directory.

>> It doesn't.  It just insists that you are consistent.  If you want
>> to write lowercase, do so.  If you want to capitalize, do so.
>
> I *am* consistent: I consistently refuse to think that Mila&Nero and
> mila&nero could meaningfully refer to different entities.

Then why do you spell them differently?

>> It is a constant source for trouble in scripts of all sorts.
>
> As Lennart said: it is, with scripts written from the case-sensitive
> mindset. That's not fault of the other alternative.

String equality is not a byproduct of "case-sensitive mindsets".

> I've never had trouble with capitalization on VMS, OS/2, CP/M, DOS,
> Windows, Oasis, THEOS and other case-insensitive systems.

Tough.  I had, repeatedly so, as maintainer of AUCTeX and other
systems.  And I don't even use Windows myself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Juanma Barranquero]

On 11/22/06, David Kastrup <dak@gnu.org> wrote:

> Listing the directory.  Just
> dir
> and nothing else.

Yes. It *preserves* the case. It does not attach any meaning to the
difference. It just preserves it. That Is Good.

> It is your Windows system that throws the file name with the same
> capitalization with which it was created back at you.

Yes, a feature. Nice of you to add support to my position.

> Then why do you spell them differently?

Because writing systems allow inconsistent spellings. I'm perfectly OK
being called Juanma or juanma. I promise you that if you ever yell my
name on the street, I'll turn back towards you, even if you pronounce
it in lowercase.

> String equality is not a byproduct of "case-sensitive mindsets".

No. I don't remember talking about string equality, but filenames. I
don't know why do you try to convince me that strings and names (of
files, people, cities, whatever) are the same thing. They are not.

> Tough.  I had, repeatedly so, as maintainer of AUCTeX and other
> systems.  And I don't even use Windows myself.

Surely because AUCTeX was written without giving thought to the weird
idea that there could be case-insensitive systems in the world.

                    /L/e/k/t/u

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

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/22/06, David Kastrup <dak@gnu.org> wrote:
>
>> Listing the directory.  Just
>> dir
>> and nothing else.
>
> Yes. It *preserves* the case. It does not attach any meaning to the
> difference. It just preserves it. That Is Good.

Four legs good, two legs bad.

>> It is your Windows system that throws the file name with the same
>> capitalization with which it was created back at you.
>
> Yes, a feature. Nice of you to add support to my position.

I did not notice myself doing so.

>> String equality is not a byproduct of "case-sensitive mindsets".
>
> No. I don't remember talking about string equality, but filenames.

File names are strings.

> I don't know why do you try to convince me that strings and names
> (of files, people, cities, whatever) are the same thing. They are
> not.

But scripts have to deal with file names as _strings_.

>> Tough.  I had, repeatedly so, as maintainer of AUCTeX and other
>> systems.  And I don't even use Windows myself.
>
> Surely because AUCTeX was written without giving thought to the
> weird idea that there could be case-insensitive systems in the
> world.

Yes, that is the problem with case-insensitive systems: unless you
give special consideration to the possibility of different file names
referring to the same file, things may break.  And since the case
sensitivity may depend on the file system of the local computer or
even of a remote server, there is no way to figure this out without
actually opening files.

If you want to find out whether a specified directory is in load-path,
for example, there is _no_ reliable way to find this out, thanks to
case insensitity.  There is no matching functions that guarantees to
have the same semantics regarding case sensitivity as any particular
file system on any particular operating system.

Is `Émilie' the same file as `émilie' under Windows?  If calling a
person on the street, it will answer to `Emilie' too, likely.  What
about `ἄνθροπος'? Is it the same as `Ἀνθροπος'?  After all, accents
are normally omitted when uppercasing.  Or should that equality be
reserved to `Ἄνθροπος'?

There are languages where some lowercase letters lose information when
converted into uppercase.

Should maybe files be the same if their Soundex rendition is the same?
Wouldn't it be a bad idea for `color' and `colour' to indicate
different file names?

Different characters->different filename is a simple rule, simple to
check, simple to implement, with dependable semantics.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Juanma Barranquero]

On 11/22/06, David Kastrup <dak@gnu.org> wrote:

> Four legs good, two legs bad.

OK, David. You're so right.

                    /L/e/k/t/u

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

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> There are languages where some lowercase letters lose information when
> converted into uppercase.

For example, in the Turkish language the uppercase of i is İ, *not* I.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 00:19:28 +0100
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> > And plenty of successful operating systems have been
> > case-insensitive, so it is clearly not a bad idea, not unworkable,
> 
> It is a constant source for trouble in scripts of all sorts.  I guess
> about 20% of Windows installation problem reports with AUCTeX
> originate from capitalization mixups.

Because programmers should be educated to refrain from Posix-centric
assumptions.

> > nor particularly dangerous, difficult to implement, or hard on the
> > user. It's just another UI decision. One I like a lot.
> 
> It is a constant trouble for programmers

For uneducated programmers.  Those are the same programmers who think
there's no distinction between text and binary files (just yesterday
saw a SHA1 signature file on a prominent download site that failed to
mark binary files as needed, which made sha1sum very unhappy).

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 00:19:28 +0100
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> 
>> > And plenty of successful operating systems have been
>> > case-insensitive, so it is clearly not a bad idea, not unworkable,
>> 
>> It is a constant source for trouble in scripts of all sorts.  I guess
>> about 20% of Windows installation problem reports with AUCTeX
>> originate from capitalization mixups.
>
> Because programmers should be educated to refrain from Posix-centric
> assumptions.

That file names are strings is not Posix-centric.  And that different
strings imply different file names is certainly not Posix-centric
either, unless the principle of least surprise is reserved to Posix.

>> > nor particularly dangerous, difficult to implement, or hard on
>> > the user. It's just another UI decision. One I like a lot.
>> 
>> It is a constant trouble for programmers
>
> For uneducated programmers.

For every programmer.  It is just that some already know most of the
moves and details customarily used to deal with that.  But they still
need to deal with it, and with varying degrees of complication
depending on the application.

> Those are the same programmers who think there's no distinction
> between text and binary files (just yesterday saw a SHA1 signature
> file on a prominent download site that failed to mark binary files
> as needed, which made sha1sum very unhappy).

Features that require "educated programmers" should offer reasonable
value in exchange.

The distinction between text and binary files has the advantage of
being able to copy a text file unchanged to a line printer or terminal
without the need for terminal settings or a formatting utility.  And
it has the disadvantage that files break under all sort of
circumstances when transferred or processed.

It is historic baggage from CP/M from times where C was not used for
programming and there was no concept of a tty (and devices were not
files, anyway).

Of course, the situation is exacerbated by Macintoshs where the "put
the whole line printer CRLF sequence in the file" idea was avoided but
they chose to go with a different line ending character than Unix/C.

I seem to remember that with Darwin, they switched the defaults, but
the inheritage is there to stay pretty much for eternity (for example,
within EPS files created on Mac and NeXT).

Avoiding complications in design is not just a question of
accommodating "uneducated programmers".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 10:53:46 +0100
> 
> That file names are strings is not Posix-centric.

Most other filesystems are case-insensitive.

> Avoiding complications in design is not just a question of
> accommodating "uneducated programmers".

Simple designs have their demerits as well.  Witness the "cat
/usr/bin/emacs" snafu on Unix, where you can have yourself logged off
or hanged due to the fact that text and binary data are not
indistinguishable by design.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 10:53:46 +0100
>> 
>> That file names are strings is not Posix-centric.
>
> Most other filesystems are case-insensitive.
>
>> Avoiding complications in design is not just a question of
>> accommodating "uneducated programmers".
>
> Simple designs have their demerits as well.  Witness the "cat
> /usr/bin/emacs" snafu on Unix, where you can have yourself logged off
> or hanged due to the fact that text and binary data are not
> indistinguishable by design.

"not indistinguishable"?

Anyway, are you saying that terminals can't get confused by binary
data on Windows?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 20:27:47 +0100
> 
> > Simple designs have their demerits as well.  Witness the "cat
> > /usr/bin/emacs" snafu on Unix, where you can have yourself logged off
> > or hanged due to the fact that text and binary data are not
> > indistinguishable by design.
> 
> "not indistinguishable"?

Should I from now on point out and mock every minor typo in your
messages?

> Anyway, are you saying that terminals can't get confused by binary
> data on Windows?

No.  Not in the terrible way the Unix terminal can, anyway, because
the Windows terminal doesn't interpret certain sequences of characters
as commands to the terminal driver.  About the worst you can get is a
screen full of garbage and a few beeps.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 20:27:47 +0100
>> 
>> > Simple designs have their demerits as well.  Witness the "cat
>> > /usr/bin/emacs" snafu on Unix, where you can have yourself logged off
>> > or hanged due to the fact that text and binary data are not
>> > indistinguishable by design.
>> 
>> "not indistinguishable"?
>
> Should I from now on point out and mock every minor typo in your
> messages?

I was trying to figure out what point you try to be making since "due
to the fact" does not make sense at all, regardless of where I try
locating a "minor typo".

>> Anyway, are you saying that terminals can't get confused by binary
>> data on Windows?
>
> No.  Not in the terrible way the Unix terminal can, anyway, because
> the Windows terminal doesn't interpret certain sequences of
> characters as commands to the terminal driver.

That would not appear to be a consequence of "the fact that text and
binary data are [whatever] by design" at all.

> About the worst you can get is a screen full of garbage and a few
> beeps.

Which is not related to the point you tried making about text/data on
Unix, but rather a consequence of the terminal emulation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Richard Stallman]

We are not going to change the fact that Emacs Lisp symbols are
case-sensitive, nor the fact that file names on GNU-like systems
are case sensitive.  Would people please end that argument,
or take it off this list?

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

[Juanma Barranquero]

On 11/22/06, Richard Stallman <rms@gnu.org> wrote:

> We are not going to change the fact that Emacs Lisp symbols are
> case-sensitive, nor the fact that file names on GNU-like systems
> are case sensitive.

No one was proposing either thing.

                    /L/e/k/t/u

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

[Richard Stallman]

    > We are not going to change the fact that Emacs Lisp symbols are
    > case-sensitive, nor the fact that file names on GNU-like systems
    > are case sensitive.

    No one was proposing either thing.

Becuase those things are not going to be changed, arguing about the
good or bad of case-sensitivity is not useful, and I would like people
to move that argument elsewhere.

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 21 Nov 2006 23:23:37 +0100
> Cc: Andreas Schwab <schwab@suse.de>, Romain Francoise <romain@orebokech.com>,
> 	Emacs Devel <emacs-devel@gnu.org>
> 
> Having different file names map to the same file is a recipe for
> trouble.

Then links are a recipe for trouble.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 21 Nov 2006 23:23:37 +0100
>> Cc: Andreas Schwab <schwab@suse.de>, Romain Francoise <romain@orebokech.com>,
>> 	Emacs Devel <emacs-devel@gnu.org>
>> 
>> Having different file names map to the same file is a recipe for
>> trouble.
>
> Then links are a recipe for trouble.

They certainly are, and this includes `.' and `..'.  However, they
offer a reasonable tradeoff between trouble and utility.

And they don't violate the principle that listing a directory will
tell you all legal _file names_ available from that directory.  I can
decide whether the file `/fdsaf/dsafd/asfd/daffa' can exist by looking
at the directory listing of `/fdsaf/dsafd/asfd/'.

That is not possible with case insensitive file systems unless I have
a function that is guaranteed to compare file names exactly in the
same manner as the operating system does.

And if I have such a function, it might mean that I can't use file
names as an index into a hash data structure unless I have a hash
function that maps operating-system-identical file names onto
identical keys.

And so forth and so on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Wed, 22 Nov 2006 10:35:46 +0100
> 
> And they don't violate the principle that listing a directory will
> tell you all legal _file names_ available from that directory.  I can
> decide whether the file `/fdsaf/dsafd/asfd/daffa' can exist by looking
> at the directory listing of `/fdsaf/dsafd/asfd/'.
> 
> That is not possible with case insensitive file systems unless I have
> a function that is guaranteed to compare file names exactly in the
> same manner as the operating system does.

The Windows API does have such a function.  Heck, even DOS had it.
And it can be emulated on Posix filesystems with readdir and fnmatch.
It's a non-issue.

> And if I have such a function, it might mean that I can't use file
> names as an index into a hash data structure unless I have a hash
> function that maps operating-system-identical file names onto
> identical keys.

Repeat after me: file names are not strings.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Wed, 22 Nov 2006 10:35:46 +0100
>> 
>> And they don't violate the principle that listing a directory will
>> tell you all legal _file names_ available from that directory.  I can
>> decide whether the file `/fdsaf/dsafd/asfd/daffa' can exist by looking
>> at the directory listing of `/fdsaf/dsafd/asfd/'.
>> 
>> That is not possible with case insensitive file systems unless I have
>> a function that is guaranteed to compare file names exactly in the
>> same manner as the operating system does.
>
> The Windows API does have such a function.  Heck, even DOS had it.
> And it can be emulated on Posix filesystems with readdir and fnmatch.
> It's a non-issue.

Which must be why neither Emacs nor Bash nor likely any other
application get this non-issue right.

I don't say that fixing this should be a high priority, but I find the
stance "there are no problems with case-insensitivity except
programmer incompetence, and if you point out anything I'll deny it"
disingenuous.

Given this "four legs good, two legs bad" argument style sanctifying
the status quo, I am really glad this "discussion" can be dropped
since we don't need to resolve anything in this regard.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Stuart D. Herring]

> That is not possible with case insensitive file systems unless I have
> a function that is guaranteed to compare file names exactly in the
> same manner as the operating system does.
>
> And if I have such a function, it might mean that I can't use file
> names as an index into a hash data structure unless I have a hash
> function that maps operating-system-identical file names onto
> identical keys.
>
> And so forth and so on.

In hopes of better defining the dilemma, some of the forth and on that
might otherwise be missed: the filesystem-comparison function, in addition
to the obvious business with mountpoints, must be an equivalence relation:
in particular, it must be transitive.  This worsens the aforementioned
issue of i, I, and İ for obvious reasons: the latter two must be
considered distinct in Turkish, but English considers the first two
identical-up-to-case and Turkish considers the first and last IUTC. 
Certainly each filesystem could have its own equivalence relation, but the
creation of a filesystem just to hold files whose names are in a different
language causes its own problems (such as defeating the rather reasonable
idea of hardlinking English and Turkish words to the same file to provide
simple bilingual support).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

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

[Stuart D. Herring]

>> Having different file names map to the same file is a recipe for
>> trouble.
>
> Then links are a recipe for trouble.

The parallel isn't perfect: what David is really describing is having two
different strings map onto the same directory entry (or, as it has been
labelled elsewhere in the thread, the same [canonicalized] file name). 
Links don't do that; they map directory entries onto files (of course).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

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

[Eli Zaretskii]

> Date: Mon, 27 Nov 2006 11:06:44 -0800 (PST)
> From: "Stuart D. Herring" <herring@lanl.gov>
> Cc: emacs-devel@gnu.org
> >
> > Then links are a recipe for trouble.
> 
> The parallel isn't perfect: what David is really describing is having two
> different strings map onto the same directory entry (or, as it has been
> labelled elsewhere in the thread, the same [canonicalized] file name). 
> Links don't do that; they map directory entries onto files (of course).

I don't see any real difference: in both cases, two file names point
to the same data, i.e. the file can be referenced by more than one
name.

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

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Date: Tue, 21 Nov 2006 19:24:26 +0100
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> If it's any consolation, the bug you're describing doesn't happen on a
> real system, where the filesystem is case-sensitive.  ;-)

Who said that case-sensitive filesystems are more real than the other
variety?