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: Bad moves with xref-find-definitions Date: Sun, 26 Apr 2015 20:26:55 +0300 Message-ID: <553D1FDF.3050307@yandex.ru> References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <87zj5vm8h3.fsf@gmail.com> <553D022D.50508@yandex.ru> <87mw1unaj1.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 1430069271 11003 80.91.229.3 (26 Apr 2015 17:27:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Apr 2015 17:27:51 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 26 19:27:45 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 1YmQLB-0003TV-SW for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 19:27:38 +0200 Original-Received: from localhost ([::1]:51584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQLB-0006bj-4X for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 13:27:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQKq-0006Xk-92 for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:27:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmQKm-0007OJ-Re for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:27:16 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:38904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQKm-0007Ir-Lr for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:27:12 -0400 Original-Received: by wiun10 with SMTP id n10so67136095wiu.1 for ; Sun, 26 Apr 2015 10:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sAxMDXwYqLnXklUrphs957LzojB6tkJK9k93rQ7gvnU=; b=e5BYlxjxttrKkGeKJu1tFmmvfw7CU0nF/s7HFXenkDLJAKPlZRzLXsGF7zdIUW6A6V 3XfRr3rgheAD9nUUKoraBPS/CMi0dm6bD7Y1ppcjSBx4+mLqR6LNhXuJEMN77t4zEHDS rpG74YtzMEwzFzKgciEgWm+9seRFEQfwBRU87bTtAOnm6HBMNgG3rZzryv7yorhSDyQ8 tFdVyfuNyGU7+OBfkVcuL039Z3QjVwGLX91lUmJZrxoBJP+YAXvkmnjEWiZaLCOZXZqk IletmhAvQiMKAMhSeFNJZ1XT1SquqcuwoUqeBCB7llgiqRRP2HoSFJyV52hNAzaS/rAR iIfQ== X-Received: by 10.194.63.80 with SMTP id e16mr15663199wjs.56.1430069221603; Sun, 26 Apr 2015 10:27:01 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dl2sm8127865wib.2.2015.04.26.10.26.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 10:27:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <87mw1unaj1.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::22a 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:185918 Archived-At: On 04/26/2015 07:01 PM, Vitalie Spinu wrote: > Aha! I see. Would be nice to be able to flush those into some familiar > interface - IDO, HELM or at least grep-like buffers (compilation > buffers) so that one can use M-g n, M-g p without visiting the buffer. If you don't like xref--xref-buffer-mode, you're welcome to assign a different xref-show-xrefs-function. > > Not if you want to avoid duplicates. ... > > > So you can simply call `delete-dups' on ... > ^^^ cannot? Right, sorry. > What's the exact problem except abandoning lazynes? Naively I think > about it like this. Gather all candidates. Delete-dups. Then take > backends in turn and see which one contain the reference. If unique, use > that backend, else use *xref* buffer. When there are more than one, we show all matches in the xref buffer. I believe showing duplicates in there would be confusing. Or similarly, if one adapts a tags-loop-continue-like interface for this, this command would visit certain locations multiple times. > I personally never had problems with too many candidates, so "being > lazy" is completely useless feature to me. I am also not convinced you > are gaining much speed here. Each backend has to operate with its own > list of candidates anyways. Admittedly, the place where the speed improvement is the most glaring is the xref-find-apropos command. Before laziness, it was much slower than `M-x apropos'. The other problem is what to do with all the files we have to open in the process. Do we leave the buffers open? Or do we kill them after generating the list, to open again when the user navigates to a reference? Or if they abort and repeat the same command with the same (or a similar) argument.