From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#21816: elisp-mode-tests fails on a case-preserving filesystem Date: Tue, 3 Nov 2015 20:12:43 +0200 Message-ID: <5638F91B.1060601@yandex.ru> References: <86mvuv30i1.fsf@stephe-leake.org> <86y4ef16ha.fsf@stephe-leake.org> <83d1vrw0p9.fsf@gnu.org> <5638D836.8090600@yandex.ru> <5638DE4A.308@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1446574403 25365 80.91.229.3 (3 Nov 2015 18:13:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Nov 2015 18:13:23 +0000 (UTC) Cc: 21816@debbugs.gnu.org, Stephen Leake To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 03 19:13:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ztg50-00050z-TC for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Nov 2015 19:13:11 +0100 Original-Received: from localhost ([::1]:50301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztg50-0007xf-A9 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Nov 2015 13:13:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztg4w-0007wJ-9B for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 13:13:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ztg4s-00031Z-Rx for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 13:13:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztg4s-00031V-Ob for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 13:13:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ztg4s-0007l4-Bp for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2015 13:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Nov 2015 18:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21816 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21816-submit@debbugs.gnu.org id=B21816.144657436929804 (code B ref 21816); Tue, 03 Nov 2015 18:13:02 +0000 Original-Received: (at 21816) by debbugs.gnu.org; 3 Nov 2015 18:12:49 +0000 Original-Received: from localhost ([127.0.0.1]:51737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztg4f-0007kd-CP for submit@debbugs.gnu.org; Tue, 03 Nov 2015 13:12:49 -0500 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:36583) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ztg4d-0007kV-78 for 21816@debbugs.gnu.org; Tue, 03 Nov 2015 13:12:47 -0500 Original-Received: by wmec75 with SMTP id c75so93713539wme.1 for <21816@debbugs.gnu.org>; Tue, 03 Nov 2015 10:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=UCnEpn40LwCE9/+garw8yXAJsL9xzBGa1Cnz7eg5mbQ=; b=EDp6i0c45oJubuOcP/U48R2/mc9sbDob1q0Byp0Uiju8LAJwEhswDY19rV4sikudcJ hz8ILQsmJs6rBy9ILk2CO7371ahbJHflEZmBCJlqOu1majLzR/Q/atAyPvo5vcDcNzH3 cU19jSRaZfXmA1DcdHdrelrwJvByjM8/36r0cmX0BeuaSGXsrUf2kuCpnFjsVgFvAyDu GWu7WdUkLwcmYCIFhPBG4cktRHEFCui0D6bSAyiaY7ebHRlu8XTvePCCjWC7GZQQl4tq bYa+3MMz06lgbi8LboQKJhcSxhSldT9WLHhobCpv8ibkr5ZZAJPRmD1p5iJcu4EComhX b08w== X-Received: by 10.28.9.73 with SMTP id 70mr22446099wmj.42.1446574366634; Tue, 03 Nov 2015 10:12:46 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ki7sm28802583wjc.28.2015.11.03.10.12.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 10:12:45 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108370 Archived-At: 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.