From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Tue, 28 Apr 2015 02:47:41 +0300 Message-ID: <553ECA9D.6090306@yandex.ru> References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> 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 1430178509 27237 80.91.229.3 (27 Apr 2015 23:48:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 23:48:29 +0000 (UTC) Cc: 19468@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 28 01:48:13 2015 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 1Ymsl2-0004K1-Kc for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Apr 2015 01:48:12 +0200 Original-Received: from localhost ([::1]:58138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymsl2-0007c0-3i for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 19:48:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymskw-0007ao-2x for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:48:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ymsks-0002He-S1 for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:48:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ymsks-0002HU-OL for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Ymsks-0000OG-7J for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 19:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 23:48: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.14301784731467 (code B ref 19468); Mon, 27 Apr 2015 23:48:02 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 23:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:41771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymski-0000NZ-5v for submit@debbugs.gnu.org; Mon, 27 Apr 2015 19:47:53 -0400 Original-Received: from mail-wi0-f171.google.com ([209.85.212.171]:35400) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ymskf-0000N6-DM for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 19:47:50 -0400 Original-Received: by widdi4 with SMTP id di4so118735495wid.0 for <19468@debbugs.gnu.org>; Mon, 27 Apr 2015 16:47:43 -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=PykAzdGCTuwRZA61OyS7c6znCe8p4RjmXiMJg+ilm+M=; b=rYVFGjs9RTHsCQi9UL5q6RU6VM9Mynqe7ak7Gz+QHleIt+cfnzYl43VRjfT3BB4Kk3 RKOoPNiGfMZRNeVT4GT+BgKwxChcv2RTreVLXeOf3QgEMR7798vUWdvC73Mns5Yqx2jk 5ZDhk4Pi2n8UC6Sjtub08kaF3BMntgXWqeeJVUJ4N2JiAZCs8wH4QC04klZawecpp8pe M2KCLaNhqtNY5YsgEkU54RU95awlG87/pSx/CZvfZNe2+x/kx8kh+DQBObKk6lYVDSh3 VFp2+ORLcBepPn1fwDKjaAZ104vpjT6UBwpatO06mMdDbLLzaQysKm/QOhntVjwf3EkE MseQ== X-Received: by 10.180.8.34 with SMTP id o2mr24668738wia.18.1430178463764; Mon, 27 Apr 2015 16:47:43 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id kc4sm31456692wjc.2.2015.04.27.16.47.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 16:47:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <837fszx7iy.fsf@gnu.org> 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:102140 Archived-At: On 04/26/2015 05:56 PM, Eli Zaretskii wrote: > emacs -Q > M-x xref-et TAB => [No match] > > It should be autoloaded, IMO. Perhaps there should also be a > global minor mode, for those who'd like that. I don't know if we want to settle on that solution, actually. Have you seen this thread? http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg01236.html That's not so easy to wrap in a global minor mode. I'm not even sure a minor mode would be a good approach here at all. However, it's a lot more flexible than using xref-etags-mode, especially with the changes to help buffers proposed by Daniel. > . It does nothing when point is on a unique symbol: > > M-. set_cursor_from_row RET > Now, with point on its position under set_cursor_from_row, type > M-. again => nothing(??!!) happens > > I guess it looks for more symbols matching set_cursor_from_row, > finds out that this is the only one, and does nothing. This is > not useful. It should at the very least say something like > "set_cursor_from_row: this is the only match". `M-x find-tag' behaves exactly the same: even when the result is that we don't move anywhere (for the same reason), there's no helpful message. Just "Mark set" in the echo area. I don't know if adding a new message in this case will be too helpful, but you're welcome to suggest the wording. > Bonus points for > prompting for a symbol, like it does when there's no symbol at > point, because I think this is more useful in this situation. I'd take a look at the patch. > . Some problems with key bindings in the *xref* buffer: > > . RET displays the candidate listed on the current line, but > closes the window displaying *xref*, so it's not easy to try > another candidate afterwards. There's also the `C-o' binding, which displays the xref, but keeps the current focus. > I think it would be more helpful > to just switch to the window showing the definition, but leave > the *xref* buffer shown. Some packages take this approach; I don't like it. But this should be easy to implement with a user option that would slightly change the behavior of `xref-goto-xref'. Care to take a stab at it? > . You need to use the unconventional '.' and ',' to both move and > display the definitions -- this should at least be mentioned in > the initial echo-area message when *xref* is first displayed. > (This was reported as a problem in the original report, but > seems to be left unchanged.) Should those be `n' and `p' instead, by default? I've found myself using these bindings very rarely anyway, and `n' is still very close. > (Other similar Emacs modes, > like Compilation and Grep, do provide commands to move to the > next item without first switching to the buffer that shows all > the hits.) Compilation and Grep both use M-g M-n/M-g M-p, and the next-error-function variable. Do you want xref to reuse it? Would you be comfortable with forgetting the current list of errors after navigating somewhere with xref? > But what are the alternatives, if any? I could only find > something related in ada-mode and in elisp-mode. This means > that, for example, for C/C++ and Java, etags is the only > available back-end, and this change is currently just a different > UI wrapping the same basic functionality? Is there any further > development planned for the near future? There's also ggtags in GNU ELPA. I'm sure it could provide some integration, too.