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

[Dmitry Gutov]

On 11/03/2015 06:33 PM, Juanma Barranquero wrote:

> I'm OK with that, but then we need to add a comment or something to xref
> explicitly stating that, when deriving new types from xref-location (or
> xref-item, if someone adds a file slot to it for whatever reason) all
> filenames *must* be kept canonicalized.

Yes, that would need to mentioned somewhere. And if someone were to 
point me to a "canonicalize file name" function (or suggest a quick 
implementation), I'd document that right away.

> And then, someone will derive from xref-location and add propertized
> strings and will want to compare *including* the properties...

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.

> No, of course I cannot think of a use case right now, but again, it's
> infrastructure. It's there to help generalization and reuse.

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.

>  > It can be solved as above, for example.
>
> Until someone adds tests for etags and wants to compare two
> xref-etag-location instances (which include a file slot), and then they
> will have to copy the code from elisp-mode-tests.el.

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

> `equal' already is quite broad, so I'd bet
> many subtypes will never require anything more complex than the default
> xref-compare-locations.

Which is my point exactly. Let's not complicate things until we have to.

> Now that I think of it... How do you sort xref-items and xref-locations?

We display the items in the order they were returned. Works pretty well.