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: Bad moves with xref-find-definitions Date: Sat, 25 Apr 2015 22:34:06 +0200 Message-ID: <87k2x0ne0x.fsf@gmail.com> References: <87h9s6c27z.fsf@gmail.com> <553BE49B.20302@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429994079 26752 80.91.229.3 (25 Apr 2015 20:34:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Apr 2015 20:34:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 25 22:34:34 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 1Ym6mP-0001dB-V9 for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 22:34:26 +0200 Original-Received: from localhost ([::1]:49282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym6mP-0001xS-0F for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 16:34:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym6mE-0001xN-CM for emacs-devel@gnu.org; Sat, 25 Apr 2015 16:34:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ym6m9-00056m-Ct for emacs-devel@gnu.org; Sat, 25 Apr 2015 16:34:14 -0400 Original-Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:33700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym6m9-00056g-2M for emacs-devel@gnu.org; Sat, 25 Apr 2015 16:34:09 -0400 Original-Received: by wgin8 with SMTP id n8so80931837wgi.0 for ; Sat, 25 Apr 2015 13:34:07 -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=yIVasqPyccA1Oqm/DH9hPiVw5MoMj0PYwW8wF6Vdbks=; b=r+GzcIgvVZ5H7KYVLs5cJMJ1QyR725/BKtUJySryg4PG0SutJewkqh14ByyQAiVnG1 uBw57ewOy/WEc273ZOcRcmbd37vTSGTl9BRqNasxGGWa9HUapc+geBUW842MJtb5Z5jW ofspCzLEc4x2g2p/LMJjCF8TK0YxRmDonaez5tcp5nu3jD7s+CMCsY5WSxxWl73N0/6R KBKgpSakRJ71HLzZioC3LUd1MFM3fAqrPzluvgbX1rv6lV+X9OvVef0WZrpWaw2jbT1J qnf8cs8pBMQvLpPEHwt/hYipsgRD90ryzXGDjnTq2kjgrGK376USM/FWRDdb3f5/WoYo yYVQ== X-Received: by 10.180.88.72 with SMTP id be8mr7733676wib.42.1429994047691; Sat, 25 Apr 2015 13:34:07 -0700 (PDT) Original-Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id yr1sm22405029wjc.37.2015.04.25.13.34.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 13:34:06 -0700 (PDT) In-Reply-To: <553BE49B.20302@yandex.ru> (Dmitry Gutov's message of "Sat, 25 Apr 2015 22:01:47 +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::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:185891 Archived-At: >>> Dmitry Gutov on Sat, 25 Apr 2015 22:01:47 +0300 wrote: > SLIME has plenty of users who find the approach convenient. Because they just got used to it. I got used to it myself with CIDER, but at least I recognize the annoyance of flow disruption and C-u inconvenience. One RET speedup is really not worth it IMO. > And this is the first complaint we've received about that aspect, in > the four months since xref had been introduced. Most of people don't track emacs devel. I tend to upgrade every 3 months or so. So here I am, complaining first time I saw it. > Since you're usually intent on typing out the symbol name, pressing > `C-u' before that shouldn't make a lot of difference. That's not exactly correct. With IDO takes 2-3 keys to select a candidate. Navigating to a symbol and then back to the editing location takes commonly more. C-u is very difficult to get used to because it's an "afore" action and it's inconsistent with other completions in Emacs. >> 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. Human brain is tricky. Mine always chooses the cognitively easier path even if it's less efficient in terms of time or muscular effort. I couldn't get used to Cider's C-u in half a year of intensive use. Instead, I got used to tracking symbols with the cursor pretty easily. >> 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). I fail to see this difference. Instant opening of the doc on symbol under point makes as much sense to me as jumping to its definition. > But while you're only person requesting it, you can modify the > current behavior trivially with `advice-add'. Well. Cider switched to standard Emacs ways because most of other people (including the lead developer) recognized the need for the change. Good defaults are very hard, mainly because you have to abstract from you own habits and think about future generations of users. Most people get used to whatever the default is. In this respect the current default is rather unfortunate as it will make new folks use navigation commands more often than they need to. > `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. I don't quite follow. Does xref rely on completion-at-point-functions? I don't see this in the code. > 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. > 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'. One can do a lot of things in emacs. A lot of emacs users don't even know the basics of elisp. The point is that tags became more difficult to use. In some modes they work, in others they don't. True that loads of modes rebind M-. In this respect xref.el is only a marginal improvement. Whether they bind M-. directly or set xref-find-definition it's the same cake to the mortals. If you somehow could merge multiple backends into one navigation system, that would be a truly big deal. Till then `xref-etags-mode` and alike feel like clumsy workarounds. Vitalie