From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Tue, 30 Dec 2014 09:19:18 +0100 Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1419927619 25052 80.91.229.3 (30 Dec 2014 08:20:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 08:20:19 +0000 (UTC) Cc: Dmitry Gutov , 19468@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 30 09:20:11 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Y5s2E-0000cQ-OH for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 09:20:11 +0100 Original-Received: from localhost ([::1]:36032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5s2E-0007zm-2L for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Dec 2014 03:20:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5s2A-0007yT-PN for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 03:20:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5s27-0003TP-Gc for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 03:20:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5s27-0003T0-D8 for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 03:20:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y5s26-0003TK-Sg for bug-gnu-emacs@gnu.org; Tue, 30 Dec 2014 03:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Dec 2014 08:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19468 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19468-submit@debbugs.gnu.org id=B19468.141992756513299 (code B ref 19468); Tue, 30 Dec 2014 08:20:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 30 Dec 2014 08:19:25 +0000 Original-Received: from localhost ([127.0.0.1]:60687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5s1U-0003SR-FC for submit@debbugs.gnu.org; Tue, 30 Dec 2014 03:19:24 -0500 Original-Received: from mail-wi0-f175.google.com ([209.85.212.175]:38658) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y5s1S-0003SI-Ax for 19468@debbugs.gnu.org; Tue, 30 Dec 2014 03:19:22 -0500 Original-Received: by mail-wi0-f175.google.com with SMTP id l15so23605444wiw.8 for <19468@debbugs.gnu.org>; Tue, 30 Dec 2014 00:19:21 -0800 (PST) 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=iANXuGI/OTlgxi/Gbc+wG2fIzBkaY135j+FFjlyhNnY=; b=vniKgh2rK35EqDNn7/Dweho/uvQQjE+jRtyixmTwQY7fAZUXCOX91x4ijwP7NdMHhC Ep1Zm5blCrATzx5g6vqe+mgkAJp7GjyXkPT1g6XJTrc7hoeCNMEHIDA34TCTMr/C5H0h uNmqxlye8oWBp5N1ehlEsFRpQs19YKuDhRks+i3wQZ85iIYBeU4P+GB2FGZKsZr27qa1 QJEKEjHH8GHek63onLOqKZi7AqppEmD+B3nnWYjX4KOURt/qKgNMWPxTHB+0bk6dOTLh 1dwTLlnnaq0W74F60si13tIZuHGBFgJHd0K5vFpa6oKuoHB1mHcuL8s0Ih5XcTvkM7Gz LUyg== X-Received: by 10.180.207.211 with SMTP id ly19mr104682652wic.73.1419927561834; Tue, 30 Dec 2014 00:19:21 -0800 (PST) Original-Received: from ix ([212.46.172.21]) by mx.google.com with ESMTPSA id h8sm42450363wiy.17.2014.12.30.00.19.20 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 30 Dec 2014 00:19:21 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1Y5s1O-00010K-TP; Tue, 30 Dec 2014 09:19:19 +0100 In-Reply-To: <54A24079.4020902@yandex.ru> (Dmitry Gutov's message of "Tue, 30 Dec 2014 08:04:41 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:97826 Archived-At: On Tue, Dec 30 2014, Dmitry Gutov wrote: > On 12/29/2014 10:26 PM, Eli Zaretskii wrote: > >> Why doesn't it put me on "display_line"s line, and display its >> definition at the same time? As Dmitry says: that would replace the current buffer and at the same time create and switch to the *xref* buffer. I had tried that and it didn't like it. >> This is a regression from the old tags >> feature, where just "M-. RET" will already show the first matching >> definition. It's not a regression as M-. is now a different command with a different UI. My goal was never to be 100% backward compatible with find-tag but to make something better. You lost your key binding for find-tag. Sorry about that, but there are only so many good keys. Of course, you know how to get the old key binding back. > It's a tradeoff. Otherwise, you'd see two new buffers at once, > possibly covering both windows (if you have two). And it seems > inconsistent with your further complaint that movement visits files > automatically (if it shouldn't, it shouldn't start with displaying the > buffer at point either). > > Compared to `find-tag', you see the list of all possible definitions > (and only if there are several). What are the odds that the first > location is the right one anyway? > >> Further, this buffer's name, *xref*, has no mnemonic significance, and >> there are no clues as to what it wants to tell me or what is expected >> of me. > > Would you like it to be called the same as the current command? > *xref-find-definitions-other-window*, *xref-find-apropos*, etc? I bet that after 15 minutes of using it, nobody will care what the name of the *xref* buffer is. So we can just as well use something short. [...] >> By trial and error I found out that I'm expected to move to the >> candidate I want with cursor movement keys, Trial and error isn't the worst way to learn things; at least if it doesn't take too long. Apparently you didn't even need to read any documentation, which would indicate that the UI is not so unintuitive after all. [...] >> Moving up an down is slow, probably because it visits files >> without waiting for RET or some other gesture to select a candidate For me, opening the file the first time is a bit slow, but after that moving up and down is instantaneous. [...] >> Another peculiarity is that once I press arrow once, I can no >> longer get back to the first line, the one that shows the source >> file: That's as expected. There is nothing to select on the first line. >> pressing on the 2nd line doesn't move point, but it does return >> the original buffer to the window above *xref*. Weird. > > A bit weird, yes. Would you prefer not to "return the original buffer"? I didn't implement that. It's because of the save-window-excursion in xref--next-line that Dmitry added. In my proposal the other window didn't change when the cursor didn't move. >> In sum: please make the new feature at least as good as the old one it >> replaces. You can't make progress by keeping everything the same. Helmut