From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: xref-find-matches and stuff Date: Tue, 05 May 2015 16:35:06 +0200 Message-ID: <87r3qvnld1.fsf@gmail.com> References: <5546DD4A.2080709@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430836584 3172 80.91.229.3 (5 May 2015 14:36:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2015 14:36:24 +0000 (UTC) Cc: Helmut Eller , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 16:36:19 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 1YpdxJ-0005T2-HM for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 16:36:17 +0200 Original-Received: from localhost ([::1]:39745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdxI-0004ob-Qt for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 10:36:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdwI-0004Fq-1t for emacs-devel@gnu.org; Tue, 05 May 2015 10:35:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpdwE-0005Qf-2k for emacs-devel@gnu.org; Tue, 05 May 2015 10:35:13 -0400 Original-Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:36613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdwD-0005QA-SV for emacs-devel@gnu.org; Tue, 05 May 2015 10:35:10 -0400 Original-Received: by wgiu9 with SMTP id u9so22106955wgi.3 for ; Tue, 05 May 2015 07:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=upHFKzcXRnWx7rW9byGcp9yCookESLO8zRoIO6LO0CA=; b=Xsc8Q/E3q4X79BePIYn+xKHP+jZsziOCE77hnXqLEj4PB1+VlBOaYyoeNaC4y7wZ3J n8toNPNu4qWjdMoz5KpYQYbpkZPAaXw8fjRjC4HGhp5C2z4G7vxVM6frS3tRVO4YmmwS zj4Bk98ZWelETHaoCyLJBIuIPPmwXVcV03UGY0SrOc98a+kndF/LZidR/QIDRX7qjCMk cAlTfB8HM1wIWS/L+DItmLhWJ4hhwn6jE44qQgHBOJL3H/5+gKm2gEl5mi6hUSC+nxzA nA/OIKhZLegoo67MozgAM2ZAjvbGKtPaSIVFW4Y8M9vk36UvgX2mSxRRbkMM8Rl1fnXT 30lA== X-Received: by 10.180.98.230 with SMTP id el6mr4728335wib.16.1430836508570; Tue, 05 May 2015 07:35:08 -0700 (PDT) Original-Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id l6sm25892144wjz.4.2015.05.05.07.35.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 07:35:07 -0700 (PDT) In-Reply-To: <5546DD4A.2080709@yandex.ru> (Dmitry Gutov's message of "Mon, 4 May 2015 05:45:30 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::232 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:186235 Archived-At: I got a bit of time to look through the abstractions. Here is my concrete suggestion. As I already said in other place, current old-school polymorphism with `xref-find-function`, xref-identifier-at-point-function' and `xref-identifier-completion-table-function` is rather clumsy if you want to build an UI for backend manipulation. You are already using class machinery, so how about to shift the focus on backends and use generics instead. More concretely: (cl-defmethod xref-definitions ((b (eql elisp)) id) (message "elisp definitions: %s" id)) (cl-defmethod xref-references ((b (eql etags)) id) (message "etags references: %s" id)) (cl-defmethod xref-apropos ((b (eql elisp)) pattern) (message "elisp apropos: %s" pattern)) (cl-defmethod xref-matches ((b (eql elisp)) pattern) (message "elisp matches: %s" pattern)) Then you can simply. (xref-definitions 'etags "blabla") (xref-matches 'elisp "blabla") Once that's done, you can introduce (setq xref-backends '(elisp etags ...)) for current backends. Then adding functionality to add/remove backends from current list and rotate through different preset configurations of backends is a piece of cake. Alternatively you can still go with more monolithic (cl-defmethod xref-find ((b (eql elisp) action id))) but this has an obvious drawback that whenever you add a new `xref-find-SOMETHING` you need to go back and modify all `xref-find` methods. Not quite an option for a good design IMO. As to removing duplicates, I don't see it as a big deal. You can define `xref-loc-name` methods for location objects to extract a wanna-be-unique name to be specifically used in comparison between backends. Even if you cannot get rid of all duplicates it's the task of the *xref* UI to provide sorting and duplication removal on specific attributes. If you are willing to wait till 20th of May I can propose patches for this abstraction change and other UI ideas that we have discussed elsewhere. Vitalie