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:51:02 +0300 Message-ID: <553D2586.6060809@yandex.ru> References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> <553BE6F2.4030604@yandex.ru> <87fv7ondlr.fsf@gmail.com> <553C5D75.9060706@yandex.ru> <874mo3np7t.fsf@gmail.com> <553CFF9F.2030502@yandex.ru> <87fv7mn9is.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 1430070714 32270 80.91.229.3 (26 Apr 2015 17:51:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Apr 2015 17:51:54 +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:51:41 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 1YmQiO-0004Pc-2X for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 19:51:36 +0200 Original-Received: from localhost ([::1]:51643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQiN-0006wD-Aa for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 13:51:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQiB-0006w8-Ls for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:51:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmQi6-0006lu-MV for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:51:23 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:35637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmQi6-0006lC-Fu for emacs-devel@gnu.org; Sun, 26 Apr 2015 13:51:18 -0400 Original-Received: by widdi4 with SMTP id di4so74741103wid.0 for ; Sun, 26 Apr 2015 10:51:07 -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=08hVQFanb+R+eOlyhBNKHy6anQ6D1tiLaLYJu2Gv9XA=; b=hkZPX58KEZnxS7OOAjhb5thVQf3KwxoRlNYJMW0+lsuW/eMgKjCm7cTX6TmmsUmI2G VAnscoa1ob+bxWTsCJ9JGsiby7N//+bYVabtQDmvAK7+xQmrkHhsSuc+eblZaIiaFyxd QOjTi/tN3YD4hGNl5WyacTT+cWZ9JRYG7GHM/xMxFC/NBhB0tnYnmijAZVbo9UzQbcjm Mi988UxeAIPZnnnadcNA4e7rkZPA04K9KDV0nkYtm6+nii9sq9qp9wll31xhGayjT8QD 2Vnr40yrfL8ZvwhE9aytmpLUn24rjUOpn8UqXdCD74tb7JZsH4csFqiPepyP/eQ9tNrh EyUA== X-Received: by 10.194.171.1 with SMTP id aq1mr15852230wjc.38.1430070667629; Sun, 26 Apr 2015 10:51:07 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id wo10sm25967137wjb.35.2015.04.26.10.51.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 10:51:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <87fv7mn9is.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::230 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:185919 Archived-At: On 04/26/2015 07:23 PM, Vitalie Spinu wrote: > Not ideal but at least it's context free. And you don't need it that > often from other places anyways. I'd rather keep it as C-h f/v/o/m, and add snappier binding(s) for context-dependent command(s). > > Personally, I expect "serious" backends to either replace the need for etags > > entirely, or delegate to them and collect the results internally. > > It's not really possible. Sometimes you just need to open related > project without "sourcing" it or an old version of the current project > to keep it as a reference. No "serious" backend can accommodate that. Why not `M-x projectile-switch-project', or something similar? > Besides etags it might be potentially handy to have multiple backends > within a mode. In clojure for example you can have one backend for pure > clojure code and another for java code. If xref is able to merge > backends and provide a nice UI to manage those backends then CIDER would > not need to bother with merging or managing those. I fail to see the benefits of keeping Clojure and Java identifiers separate. The commands easily choose one or the other based on the context, and if you're typing the identifier manually, the Java ones look distinctly different. Also, while CIDER knows that Java and Clojure identifiers have no duplicates between them (and can simply concatenate the lists, or something to that effect), the generic code cannot know that. > As this and other threads suggest managing backends is a non-trivial > task. If you leave this task to major modes everyone will cook his own > soup resulting in a variety of different interfaces. If I have to guess, the built-in major modes will use comparatively simpler approaches (like python-mode's delegation to the REPL process to fetch completions), but third-party minor modes can provide smarter integration. I definitely don't want to see here micromanagement a la Icicles in the default interface.