From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: xref-find-matches and stuff Date: Wed, 6 May 2015 03:48:14 +0300 Message-ID: <554964CE.3040809@yandex.ru> References: <5546DD4A.2080709@yandex.ru> <87r3qvnld1.fsf@gmail.com> <5548E08A.4090305@yandex.ru> <87mw1jndul.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430873337 28236 80.91.229.3 (6 May 2015 00:48:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 May 2015 00:48:57 +0000 (UTC) Cc: Helmut Eller , emacs-devel To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 06 02:48:44 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YpnW0-0008LE-6s for ged-emacs-devel@m.gmane.org; Wed, 06 May 2015 02:48:44 +0200 Original-Received: from localhost ([::1]:42427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpnVz-00011h-Mp for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 20:48:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpnVl-000119-Dl for emacs-devel@gnu.org; Tue, 05 May 2015 20:48:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpnVi-0004hd-22 for emacs-devel@gnu.org; Tue, 05 May 2015 20:48:29 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:33033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpnVh-0004g8-N7 for emacs-devel@gnu.org; Tue, 05 May 2015 20:48:25 -0400 Original-Received: by wief7 with SMTP id f7so113650591wie.0 for ; Tue, 05 May 2015 17:48:16 -0700 (PDT) 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=nmeXWsKDF0lsj1Prr9dcOq7z1IPrARjqPl83d479Zhs=; b=m8p7iiXSYsnbPm0qQeghSCucT2AZrhIPFY3nETTaKnfDh8/RGoyVQm9eXI+dsDyy8a j5wTGEKa6GzkiYK+GdsCeptbY6rs4kxPLwTBYVs55vfok0jRYoof+QZbKmyVcACNxxhZ IN6p8BIS0VaTGogBTqTWCBs2bY2tlwqK7SJiXF3QwznJsIeUhkI0RQxNsbmzuYpK7wvZ MtcPaVbgVcj2z9RHZyhi7TsKtGqNBhMdqyMz4g39dAX+LqqiYqoL7w14rBJ5H1Ce/YXE p3bsXgOWsPHrvgBci+K/fymwZHTtlOsh9s32u0UCOor8k+ovZPVxAcpE11Vq/JhyEaUH xb6A== X-Received: by 10.180.93.36 with SMTP id cr4mr69041wib.61.1430873296745; Tue, 05 May 2015 17:48:16 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id gs7sm542691wib.10.2015.05.05.17.48.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 17:48:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <87mw1jndul.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186267 Archived-At: On 05/05/2015 08:17 PM, Vitalie Spinu wrote: > I don't quite understand your opposition. Multiple backends is such a > common requirement that you will need to set 'xref-multi by > default. I guess I don't see it that way. We currently don't have multiple values in any major mode. The third-party project I intend to use xref in, won't have them too. Feel free to make the case with specific examples; maybe implement a usable elisp+etags configuration. Without multiple values in the core, I can avoid asking questions like: - If I'm a major mode, what do I do with xref-backends? Do I set it to a single-value list? Do I prepend to it? Out usual strategy is to use a hook (like a list of functions), but in those kind of setups, we usually run the hooks until one of the elements returns something interesting, rather than combining all results. - If I'm a minor mode, what do I do with it? - How are xref-identifier-completion-table-function values combined? completion-table-merge, or completion-table-in-turn? What are performance characteristics of calling completion-table-merge on five tables? Are you aware that a completion table produced by either of these functions can't handle certain advanced metadata that might be present in some of the original completion tables? > Having a parallel xref-multi engine would necessary involve > replication of variable names and, hence, needless burden on the users > and developers. What's the point? What variables? I can only see one: xref-multi-backends. Then you set xref-backend to `xref-multi' in the minor mode function and implement the four or so methods on it, delegating each to the current list in xref-multi-backends, and combining the results somehow (nconc, for most of them). > Anyways, I expect it to be no more than 100 lines of code. So I can > implement it both ways and we can see which one is better afterwards. Since the simplest implementation can be very simple, it can also be an argument not to have it in the core. Backend author can make the choice, if it comes with this low a cost. > Of course. This one is a particularly interesting example. Both etags > and elisp return name and file, but elisp doesn't return a line. So in > order to make them compatible you must avoid using lines in the uniform > identifier. So it could be in file:symbol:type format, or > editfnc.c:system-name:defun in your example. Yup. Or rather /path/to/editfns.c:system-name:defun (etags has the full path, elisp doesn't; we should expand it). > I think this is a general enough convention that will probably work > reasonably well in most of the cases. You can also have several levels > of "uniqueness" of the uniform identifier, xref-uname-lax, xref-uname > and xref-uname-strict. The lax one can be file:symbol; the strict one > can be file:symbol:type:line:column. The last one is redundant: if we have file, line and column, we don't need the symbol and its type. However, note that both representations you've chosen require a file name. Currently, an xref could only include some info that it needs to find out the file name (lazily), and it can return something else as its "group". We can only enable duplicate-remove-ability for certain types of xrefs, though. > In *xref* buffer you might have a command that will rotate through > levels of "uniqueness". FWIW, that's too many user choices for my liking. > I meant that if you already got into *xref* buffer with many > alternatives there should be commands to refine duplicates on different > criteria, just as I have described above. See above. Don't ask the user to do what a machine could. If unwanted duplicates happen, we should write smarter backends. > The problem still remains when you have small number of matches that > give the same location. You don't want to popup *xref* in that case. But > I think the above uniform identifier idea will reduce this problem to > minimum. I think duplicates removal is kind of important, especially for xref-find-definitions. It's the difference between having to choose and being taken to the right option immediately. > This looks like an over-engineering to me. Why to allow locations to > display differently? To bother users with different colors and > arrangements? Do you have examples when different location classes need > to display differently and simple non-generic display would not work? It's an implementation technique. The fact that a backend implementor will be able to insert a nyancat animation after every line doesn't mean they will; everyone can mess will any Elisp function anyway, and don't get me started on custom faces that don't fit the default theme, or any light-background one. Anyway, the fact that some people could too easily change a piece of Emacs behavior to their liking shouldn't be an argument against this. So far it looks right: - You want shortened file paths, a "file path" group class would fit. - Helmut suggested that xref-find-apropos output for Elisp looks closer to M-x apropos. We could do that with special elements. Likewise, apropos output for a different language would look different and use different properties, which we cannot anticipate. Flexibility here should be beneficial. - Elements can have different roles; for instance, a group could also be an xref. Like, for instance, xref-find-references can match something in a function declaration (name or argument), and some references inside it. The output could have the method displayed as a match, as well as group the matches inside it. - In certain cases, a file name might be a match for a search, so it could be fitted into the hierarchy. In an environment where classes and file names are usually tied (like Java or Ruby), a rename operation, ideally, should handle both. If, on the other hand, a fixes set of structures is all we need for the data returned by the backends, the backend authors might limit themselves to the built-in ones, and avoid spending effort on extensions. > Anyways, I want my locations to display the same and have same UI for > all backends, so I am sticking to my tabular display. If people add new structures, we should recommend to inherit from the built-in ones. So you'd still render them automatically, even if missing some extra fields. > Would be nice if > your new generic system would allow me to easily overwrite the default > display methods for all xref-locations at once. I don't want to hunt > them one by one afterwards. The location classes are unlikely to change much. We're displaying xref--xref instances, though, and that hierarchy will see some growth. Any suggestions for a better name, by the way? xref-item?