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 03:20:01 +0300 Message-ID: <553C2F31.4070202@yandex.ru> References: <87h9s6c27z.fsf@gmail.com> <553BE49B.20302@yandex.ru> <87k2x0ne0x.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 1430007641 22077 80.91.229.3 (26 Apr 2015 00:20:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Apr 2015 00:20:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 26 02:20:29 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 1YmAJ7-0006hG-5T for ged-emacs-devel@m.gmane.org; Sun, 26 Apr 2015 02:20:25 +0200 Original-Received: from localhost ([::1]:49585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmAJ6-0002T4-9J for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 20:20:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmAJ2-0002Np-8Q for emacs-devel@gnu.org; Sat, 25 Apr 2015 20:20:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmAIx-0005PU-5U for emacs-devel@gnu.org; Sat, 25 Apr 2015 20:20:20 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:34146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmAIw-0005Fd-Ru for emacs-devel@gnu.org; Sat, 25 Apr 2015 20:20:15 -0400 Original-Received: by wicmx19 with SMTP id mx19so58750479wic.1 for ; Sat, 25 Apr 2015 17:20:04 -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=eijEtyfwCVZeqEYZrMruvsThmty2a0B/wuF3NFVocRw=; b=bLUgAhfTRv7Lv4yTD78NyuWTWPBWmU/awaU/RBm1iMVjUMv7UFxXQ6gPa6EnMMJnvv w7HIt4mzSz7RC97GOEbP6Za9Rs14YBn68lzyytUyD7bRKTrdc27f8SWpm5gwQo4+gODS ew9bpQjPXJatOnwBwsbZth7D4Zleev0a2MO6Nqy5dHbiqyqeCLoSvmsyoOaxT/soaFvE ns0X64ygPUYfRiyzcuAtVM9+c7+ilOg8677muVZUsJFnVXcrTcxwo0KBG/fA6g16bat0 z5zorVScqN8P3ufWznWjfeMxKuQEmgSjdX1eHjgh1iK3YiCt0O6mmeXU0gYcmRAvlx9X A5vA== X-Received: by 10.194.60.43 with SMTP id e11mr10237980wjr.36.1430007604709; Sat, 25 Apr 2015 17:20:04 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g14sm23021860wjs.47.2015.04.25.17.20.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 17:20:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <87k2x0ne0x.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:185897 Archived-At: On 04/25/2015 11:34 PM, Vitalie Spinu wrote: > Because they just got used to it. That's a bad explanation. It directly assumes that SLIME developers don't know what's good for them. I think we can settle on the assumption that both approaches are viable. > Most of people don't track emacs devel. Still, many do. > 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. We can really assume usage of Ido in `xref-find-definitions'. Not only it's off by default, without `ido-ubiquitous' (a third-party package) you simply can't use it with xref-find-definitions. But 2-3 keypresses sounds like a serious under-estimate to me either way. For instance, when I'm on some unrelated symbol, making `C-h f' pick `emacs-lisp-mode' forces me to type out at least half of the characters in that function's name. I'd probably type it in full until it's the first completion, which ends at `emacs-lisp-m' here. > 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. Cognitively easier paths are nothing to sneeze at. Who's to say that less muscular effort at the expense of more cognitive one is always better? Further, `C-s emacs-li' in the current buffer followed by M-. might turn out to be the same amount of keypresses, even if cursor is currently far from that symbol. > > 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. And indeed, SLIME has a set of commands that do just that. elisp-slime-nav copies it in its `C-c C-d C-d'. It's quite nice, even if I've stopped using it around those same 4 months ago. Maybe I should say that the `C-h ???' are a special set, and changing how they all behave would be harder. Those keybindings aren't as snappy as `M-.' or `C-c C-d' anyway. And find-file is inherently an operation that doesn't usually use the content at point. > > 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. Did you have a vote? From the first thread, I recall Bozhidar stating that both ways have merits. > 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. Moving point has its own benefits. For instance, when you press `M-,', you instantly see which function call the previous jump was related to. That makes following the control flow of unfamiliar code much easier. > I don't quite follow. Does xref rely on completion-at-point-functions? I > don't see this in the code. No, it's a separate feature, but the principle is the same: by default, completion uses the tags table. Major modes (and some minor modes) add elements at the beginning of that hook, effectively blocking tags-completion-at-point-function from being used in corresponding buffers. Is that a problem? Not so much. > One can do a lot of things in emacs. A lot of emacs users don't even > know the basics of elisp. We hope that those users will feel satisfied with the default behavior. > 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. Some modes use tags, other ones use facilities they consider better than tags. If you think a certain mode should use tags in more situations, that's as good cause for a bug report as any. > 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. This request is too vague, sorry. Feel free to outline a specific design in a new bug report.