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

[Juanma Barranquero <lekktu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Tue, Nov 3, 2015 at 7:12 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> Maybe they would, but you already understand that it's not a realistic
example.  Anything
> they might want to store in the properties, they can store inside their
xref-derived instance.

Yup. Though, there's this comment at the beginning of xref.el:

;; Each identifier must be represented as a string.  Implementers can
;; use string properties to store additional information about the
;; identifier, [...]

> When we add a new generic function, it's good to document exactly what is
expected
> of its implementations. Which is hard to do without knowing use cases.

I've stopped arguing for a generic comparison function (I've read the rest
of the thread and it's obvious that Stephen and you don't consider it
useful). But as a general comment, I disagree with this. A generic
function, in most languages or frameworks that define interfaces, do not
document "exactly" what is expected of the implementations. They document
the behavior in general terms. Which in this case would be: "Compare two
xref-location items and return non-nil if they are considered equal, nil
otherwise." That's *all* a generic comparison function for xref-location
should need to document.

> Why *-tests.el? Canonicalization should happen inside the constructor
function, if anywhere. E.g. inside xref-make-file-location and
xref-make-elisp-location.

I though "solved as above" meant Stephen's fix for this particular bug.

[-- Attachment #2: Type: text/html, Size: 1851 bytes --]