bug#23902: 25.1.50; Strange warning on string-collate-equalp's docstring

[Eli Zaretskii <eliz@gnu.org>]

> From: oscarfv@telefonica.net (Óscar Fuentes)
> Cc: Glenn Morris <rgm@gnu.org>,  michael_heerdegen@web.de,  23902@debbugs.gnu.org
> Date: Sat, 09 Jul 2016 23:36:37 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But they can reason this way instead:
> >
> > "I want to compare two file names.
> > Collation is a way to compare strings, for example the man page for
> > strcoll says the function returns zero if one string is equal to the
> > other.
> > And Emacs just learned how to use collation to compare strings, it
> > has this great new function string-collate-equalp.
> > Therefore, let's use string-collate-equalp for comparing two file
> > names."
> 
> This implies that the user knows about string comparisons with collation
> but he is a complete ignoramus about file systems. A bit unrealistic.

I'm not sure.  People might know a lot about strings, but not how the
filesystem stores file names.

> >> And suppose I have two strings, and want to know if they are equal,
> >> respecting my locale's convention about characters that are not
> >> literally identical, but have the same meaning. I should use
> >> string-collate-equalp for this. This is true whether the strings
> >> represent the names of elephants in a zoo, or files on a disk.
> >
> > And that is exactly the fallacy that the note warns against.  Because
> > filesystems don't compare as equal characters that have the same
> > meaning, they compare bytes in a byte stream that is the file name in
> > its raw byte form, as recorded on disk.
> 
> I think that Glenn is saying that you can compare file names for other
> purposes than knowing if they name the same file.

Then it's not "equality", it's "equivalence".