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: Sat, 25 Apr 2015 22:01:47 +0300 Message-ID: <553BE49B.20302@yandex.ru> References: <87h9s6c27z.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 1429989025 16770 80.91.229.3 (25 Apr 2015 19:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Apr 2015 19:10:25 +0000 (UTC) To: Vitalie Spinu , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 25 21:10:17 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 1Ym5Sv-00077Z-GZ for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 21:10:13 +0200 Original-Received: from localhost ([::1]:49177 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym5Su-0007nO-Lb for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 15:10:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym5Se-00078w-Km for emacs-devel@gnu.org; Sat, 25 Apr 2015 15:09:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ym5Kz-00064B-J7 for emacs-devel@gnu.org; Sat, 25 Apr 2015 15:02:04 -0400 Original-Received: from mail-wg0-x230.google.com ([2a00:1450:400c:c00::230]:33973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym5Kz-00063G-9P for emacs-devel@gnu.org; Sat, 25 Apr 2015 15:02:01 -0400 Original-Received: by wgso17 with SMTP id o17so80024319wgs.1 for ; Sat, 25 Apr 2015 12:01:50 -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:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EL7cFRBSZH5uhytbnnCnrrW7lukdeyfTHknTjSJLKCM=; b=uNrMBsrJ8oM/4q7TEEtEa6UqIlqLKcuOweoyh156kZ1Shs3FgJGVCrWmKV3Yg/oSf2 KCIY65OoO4GTD6Rph3aW3fh0nd/eBo1ApEoQ2u1CLxND6sw81GCVDKW0EE8b9VXrVrYS PMYiN4niA99eO9PK3dnzxaAzt5NNKXQF3OWnlZawh/Pgxyfvfrp4rTGD/pHSacVl+y/0 uVKiYSn92/1vPOoqVMD6D+DcCjQ2YKiFZNCzvcY6Rom0udSTv4wtAhjKao+nvHLXC2ri 8t3oR983Q8lVXVDDFc+tWJU6y4GZBf+5T35h15pPmGoHAkJ1vyAOIh4pUz00JVdya68F ZCGg== X-Received: by 10.194.81.169 with SMTP id b9mr7558661wjy.126.1429988510823; Sat, 25 Apr 2015 12:01:50 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g14sm22134982wjs.47.2015.04.25.12.01.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 12:01:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <87h9s6c27z.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::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:185887 Archived-At: Hi there, On 04/23/2015 06:07 PM, Vitalie Spinu wrote: > There has been a breaking change in UI with respect to find definition > functionality. I am all for generic interface but IMO there is no reason > to break standard Emacs interaction mechanism in favor for some not that > well thought UI borrowed from SLIME. SLIME has plenty of users who find the approach convenient. You should notice that in both CIDER discussions you've referenced that opinion has also been expressed. When discussing the options for the new UI to replace `find-tag', both initial proposals also opted not to prompt by default [1][2]. And this is the first complaint we've received about that aspect, in the four months since xref had been introduced. > 1) `find-tag` (previously bound to M-.) was prompting for a symbol > before jumping to the definition. The symbol at point was the > default. On the expense of one additional RET this was very > convenient because it leaves the possibility to jump to a different > symbol and also saves you from useless navigation to a symbol when > symbol is not directly under the cursor. The desired symbol might > not be visible, or even present in current buffer. Since you're usually intent on typing out the symbol name, pressing `C-u' before that shouldn't make a lot of difference. On the other hand, when "jump to the symbol at point" is a frequent operation, it makes sense to optimize it. > Now, "xref-find-definitions" encourages you to navigate to a symbol > by disrupting the flow twice. Once, when you navigate to a symbol, > and often for the second time when you need to go back to the > editing after you saw the definition. This just fosters a bad habit > of tracking what you read with a cursor. It just cannot be right. I don't know if it's a bad habit. Apparently, it's a common one. > Needless to say that most other functionality in Emacs does ask for > completion before performing an action (documentation, find-file > etc). In my view, "jump to the thing at point" is a different kind of operation (and it can work with symbols, file paths, etc). It also has correspondence in other editors: Ctrl-] in Vim, or Ctrl+Click in IDEs. > Having an option to *not* navigate to symbol is very useful and > Emacs was recognizing this need all this time. Why would you change > this now? The question could as well be, why wasn't it changed sooner. Anyway, this behavior can be customizable, like suggested by Michael Griffiths in the second CIDER discussion. But while you're only person requesting it, you can modify the current behavior trivially with `advice-add'. > Etags is still very useful even with dynamic languages. For example > the language tool might not load all the files in current > project/directory, or you might intentionally keep some code in > non-project directories. You might also define your tags for a > bunch of other related projects which you want to access from the > current project. `completion-at-point-functions' defaults to `'(tags-completion-at-point-function)'. Are you also worried about a major mode overriding it? That's the whole point of adding this kind of variable. And if by any chance the major mode does a poor job, you can use xxx-mode-hook to override it back. In this case, there already exists `xref-etags-mode', because of a prior request. > Now, when "M-." is gone, if the language re-defines > `xref-find-function` how do I access tags? Do I need to bind a new > global key for `find-tag` command? You can also add a separate binding for it. And if/when `find-tag' goes away, you can use that binding for a new command wrapping `xref-find-definitions'. By the way, it seems I've forgot to declare `find-tag' obsolete. > There has been a lengthy discussion on Cider issue tracker to change the > behavior borrowed from SLIME into standard emacs UI [1][2]. Once that > was changed, emacs itself seems to move into wrong ways. Maybe the fact that Emacs currently behaves in a certain some way is not always a bullet-proof argument in its favor. [1] http://lists.gnu.org/archive/html/emacs-devel/2014-11/msg01302.html [2] http://lists.gnu.org/archive/html/emacs-devel/2014-11/msg01684.html