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 20:49:14 +0200 Message-ID: <87oamcnivp.fsf@gmail.com> References: <87h9s6c27z.fsf@gmail.com> <87zj5wnlyt.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429987967 865 80.91.229.3 (25 Apr 2015 18:52:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Apr 2015 18:52:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 25 20:52:37 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 1Ym5Bn-0000tZ-S4 for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 20:52:32 +0200 Original-Received: from localhost ([::1]:49149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym5Bm-00038r-TF for ged-emacs-devel@m.gmane.org; Sat, 25 Apr 2015 14:52:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym5BX-000303-JI for emacs-devel@gnu.org; Sat, 25 Apr 2015 14:52:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ym58h-0002e8-9A for emacs-devel@gnu.org; Sat, 25 Apr 2015 14:52:15 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:37335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ym58h-0002e4-2P for emacs-devel@gnu.org; Sat, 25 Apr 2015 14:49:19 -0400 Original-Received: by widdi4 with SMTP id di4so51516384wid.0 for ; Sat, 25 Apr 2015 11:49:16 -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=ZF8h8zFPOyX5p9Qq+INVVqUzqy1ppTeS1gfCRllOxbo=; b=Hnzda1qWpGQjKVLMy2rafiyUCY7hxD9YJ9zslXdCX3rJrXkZkcl5LLJHrVe92/kdtD 6EIjkgLc7t0icVGISndMrBBinLw6fZpAhEAzG76vp5nBiNTuICsRjhQhF/c9Vx/ZphBX EIrau8YpQ/Lxie3rVVxjGDqzwcviuj/Sk6f68+4Us8mpXVeWxaOSMzzRlyXVrQacu/jv hZi70qcAVkoMRD/uRX26Umkb1KGeEB+KqAQPL+zvVSLkvI6QFovS4SRrXvFqKdYaEUG9 9oON+KIDNir0kbyU4sTSulixGKEH5MZn/b3NRbZg2dbjtXkg1W7CApXDifTzWS0+y8Ju nQDA== X-Received: by 10.181.12.47 with SMTP id en15mr7040376wid.4.1429987756273; Sat, 25 Apr 2015 11:49:16 -0700 (PDT) Original-Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id n3sm4441475wix.1.2015.04.25.11.49.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 11:49:15 -0700 (PDT) In-Reply-To: <87zj5wnlyt.fsf@gmail.com> (Vitalie Spinu's message of "Sat, 25 Apr 2015 19:42:34 +0200") 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:c05::236 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:185884 Archived-At: As to my 2nd original point. I think the exclusive approach of tags *or* dynamic completion is not the correct one. There should be a way to merge tag candidates with dynamic candidates. Having C/C++ api interface to higher order languages is a commonality rather than an exception nowadays. So maybe xref-identifier-completion-table-function and xref-find-function should be better lists of functions to allow for grouped backends? Vitalie >>> Vitalie Spinu on Sat, 25 Apr 2015 19:42:34 +0200 wrote: >>> Stefan Monnier on Sat, 25 Apr 2015 10:24:29 -0400 wrote: >>> 1) `find-tag` (previously bound to M-.) was prompting for a symbol >>> before jumping to the definition. >> You can still get the prompt, with C-u. > That's a bit besides the point. I want my interface to behave exactly > the same independently of the context at point. I also want consistency > with all other emacs completion. And, most importantly, I don't want to > foster bad habits because my brain always chooses the easy path - > navigate to a symbol instead of C-u. > C-u is an awkward solution. You always have to think before the actual > key press. Is the point on a symbol? Do you need that symbol? Is the > symbol that I need close enough to navigate to it? Shall you press C-u, > or maybe navigate to an empty space? All this pain for a marginal > speed-up in a rather corner case. > On radical UI changes a backward compatible option should be > provided. Especially in this case with so many arguments against the new > interface. > Such changes should be broadly discussed. Somewhat surprisingly the > thread that started the generalization [1] hasn't touched the issues > that I have raised. > So please. Could you please bring the standard Emacs UI back? > Thank you, > Vitalie > [1] http://comments.gmane.org/gmane.emacs.devel/176235