From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Bad moves with xref-find-definitions Date: Sun, 26 Apr 2015 22:26:42 -0400 Message-ID: References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <87zj5vm8h3.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430101626 26557 80.91.229.3 (27 Apr 2015 02:27:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 02:27:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 27 04:26:58 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 1YmYl3-0005Ya-SA for ged-emacs-devel@m.gmane.org; Mon, 27 Apr 2015 04:26:54 +0200 Original-Received: from localhost ([::1]:52822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmYl3-0007MS-78 for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 22:26:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmYl0-0007KO-I7 for emacs-devel@gnu.org; Sun, 26 Apr 2015 22:26:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmYkw-0004M6-Di for emacs-devel@gnu.org; Sun, 26 Apr 2015 22:26:50 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:40964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmYkw-0004Lq-83 for emacs-devel@gnu.org; Sun, 26 Apr 2015 22:26:46 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3R2Qgrp025181; Sun, 26 Apr 2015 22:26:43 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9DCB12189; Sun, 26 Apr 2015 22:26:42 -0400 (EDT) In-Reply-To: <87zj5vm8h3.fsf@gmail.com> (Vitalie Spinu's message of "Sun, 26 Apr 2015 13:31:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5288=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5288> : inlines <2797> : streams <1429215> : uri <1916445> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:185924 Archived-At: > Backend has to figure out the "thing" anyways. From there building > "textual representation" and passing back to xref is a triviality. Apparently not, because the part of the backend which "figures it out" might be in an external tool which simply doesn't offer the option to build a textual representation for it. > Also, you have to provide completions and textual representation of on > C-u anyways. In case the backend is as described above, the C-u path will lead to suboptimal results, indeed, because it'll have to fallback on other techniques. > What do you currently do if there are multiple matching definitions of > the "thing-at-point"? Prompt? Yes, in the *xref* buffer. > All I was trying to say is that tags are commonly useful alongside > dynamic backends. Blindly replacing tags with an even very good > backend is not the right direction IMW. Expecting from end users to > solve this problem with add-function :before is unacceptable if there > are way to fix it at Emacs level. I'm not talking about the end-user using add-function, but about the major mode's xref's backend doing so. > Different backends can figure different "things-at-point". It would be > wise to try back-ends in turn, just like completion-at-point-functions > does. If the major mode adds the backends via (add-function :before-until ...) that's exactly what will happen. Stefan