bug#21816: elisp-mode-tests fails on a case-preserving filesystem

[Stephen Leake <stephen_leake@stephe-leake.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: dgutov@yandex.ru,  lekktu@gmail.com,  21816@debbugs.gnu.org
>> Date: Tue, 03 Nov 2015 15:58:49 -0600
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> >> Cc: Juanma Barranquero <lekktu@gmail.com>, Eli Zaretskii
>> >> <eliz@gnu.org>, 21816@debbugs.gnu.org
>> >> Date: Tue, 03 Nov 2015 13:54:21 -0600
>> >> 
>> >>    If the file name identifies an existing file, convert the file name
>> >>    casing to match the actual file name casing. If not, no case
>> >>    conversion is done.
>> >
>> > For existing files we have file-equal-p, which is more general.  
>> 
>> You missed the context; we have switched from discussing how to compare
>> file names to how to canonicalize a file name, in order to simplify the
>> comparison.
>
> I'm still trying to convince you that this is a dead end: you cannot
> trust user-extensible code to comply with such requirements, on
> filesystems where "canonicalized file name" is not well defined.

We can provide a `file-canonical-name' that does something useful on all
systems.

I believe the notion of "canonical file name" is well defined for
existing files on all systems we care about; is that not true?

For non-existing files, I don't think there is a real problem in
practice (see other email); can you present a use case where there is?


The file-equal-p option does not fix the problem in xref--analyze, since
that is comparing the result of `xref-location-group', which is yet more
user-extensible code; for xref-elisp-location, that is the file name
slot of the location. Using file-canonical-name in xref-location-group
implemetations would fix this; using it in make-xref-location fixes it
in a more robust and consistent way.


To summarize:

The problem is comparing xrefs directly (for sorting and testing),
comparing the result of xref-location-group (for sorting), and possibly
comparing results of other xref access functions in the future. Note
that any filenames in xrefs identify existing files, except in
artifically constructed tests.

I believe the two alternatives being proposed are:

1) Use `file-equal-p'

- Provide a cl-defgeneric `xref-location-equal-p' for the root
  xref-location type.

- For each type that inherits from xref-location, provide an
  implementation of `xref-location-equal-p' that uses `file-equal-p' for
  each file name.

- Provide a cl-defmethod `xref-equal-p' for the root xref type that uses
  `xref-location-equal-p' for the location.

- For each type that inherits from xref, provide an implementation of
  `xref-equal-p' that uses `xref-location-equal-p' for each location.


2) Use `file-canonical-name'

- A canonical file name has the following features:

  It contains forward slashes for directory separators.

  If the file name identifies an existing file, the canonical file name
  casing matches the actual file name casing. If not, the case of the
  portions of the canonical file name that do not exist is arbitrary.
  Note that this matters only on case-insensitive file systems.

  Two different non-canonical names for an existing file convert to the
  same canonical file name. Note that this means symlinks are resolved.

  Canonical file names may be compared with `string-equal' and
  `string-lessp'.

- Provide a system-dependent `file-canonical-name' that converts
  user-provided file names to a canonical file name.

- Require each variant of make-xref-location to use it for file name
  slots.


Option 1) solves the problem of comparing xrefs and xref-locations, but
does not solve the problem of comparing results of xref-location-group.

Option 2) solves the problems of comparing xrefs, xref-locations,
results of xref-location-group, and results of future xref access
functions.

So far, `file-truename' seems adequate for `file-canonical-name', but it
might be best to define the alias, in case we find problems in the
future.

One problem with canonical file names is that the user can construct two
names for a non-existing file that differ only in case; they are
supposed to convert to the same canonical file name on a
case-insensitive file system, but `file-canonical-name' has no way to
know which might represent an actual file in the future. One solution is
for `file-canonical-name' to downcase the portions of the file name that
do not exist, but that's not very user-friendly (`file-truename' does
not do this). This problem does not seem likely to occur in practice.


Option 2) seems better to me. 

-- 
-- Stephe