From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19468: 25.0.50; UI inconveniences with M-. Date: Mon, 27 Apr 2015 22:26:40 +0300 Message-ID: <83k2wxwexb.fsf@gnu.org> 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> <83r3r5wqwv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1430162844 26289 80.91.229.3 (27 Apr 2015 19:27:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Apr 2015 19:27:24 +0000 (UTC) Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 27 21:27: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 1YmogQ-00071B-56 for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 21:27:10 +0200 Original-Received: from localhost ([::1]:57400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmogP-0007mg-GL for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Apr 2015 15:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmogM-0007mb-1d for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:27:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmogI-0004NG-Mb for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:27:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmogI-0004NC-Ij for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YmogH-0004v8-VI for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2015 15:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Apr 2015 19:27:01 +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.143016281918906 (code B ref 19468); Mon, 27 Apr 2015 19:27:01 +0000 Original-Received: (at 19468) by debbugs.gnu.org; 27 Apr 2015 19:26:59 +0000 Original-Received: from localhost ([127.0.0.1]:41535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmogE-0004ur-Ir for submit@debbugs.gnu.org; Mon, 27 Apr 2015 15:26:59 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:52751) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YmogB-0004ud-E3 for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 15:26:56 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNH00900BSMB800@mtaout24.012.net.il> for 19468@debbugs.gnu.org; Mon, 27 Apr 2015 22:18:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNH002T4CA1IA70@mtaout24.012.net.il>; Mon, 27 Apr 2015 22:18:01 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:102105 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org > Date: Mon, 27 Apr 2015 13:35:25 -0400 > > >> I don't understand exactly the scenario you're talking about. Can you > >> give a recipe? > > > > Yes: > > > > emacs -Q > > C-x C-f lisp/simple.el RET > > M-. find-tag RET > > > > This puts you at the first line of find-tag, without showing the other > > possible symbols whose names contain "find-tag" as their substring. > > Yes, that's the expected behavior, and matches the behavior of Emacs-24. Emacs 24 also had "C-u M-." to go to the next one. This one doesn't; moreover, if you try "C-u M-.", you get prompted for the symbol again, and if you type the same one, you get nowhere. The other matches are only available via completion, see below. > Is that a behavior you like or a behavior you dislike? It's surprising, since I expected to see the *xref* buffer, as I understood this is the core of the new UI. But it sounds like the back-end can easily affect the UI in radical ways, which I think is not a good thing: the entire idea of the back-end means to me that the front-end is not affected, UI-wise. > > By contrast, this: > > > > emacs -Q > > C-x C-f lisp/simple.el RET > > M-x load-library RET xref RET > > M-x xref-etags-mode RET > > M-. find-tag RET > > > > does NOT show the definition of find-tag, but instead opens an *xref* > > buffer with possible matches, and expects you to pick one of them (and > > Indeed, one of the differences in the new UI is that we don't have the > "C-u M-. lets you cycle among matches" any more. Instead we pop up an > *xref* buffer where you can choose the match that interests you. I find > this easier (and generally faster) to use. OK, but then why aren't we shown *xref* in the first case? > > But it's confusing to have such evident differences just because you > > changed the back-end, I think. > > But popping up the *xref* buffer when there's only one element in it > doesn't make much sense I think. Oh, but there shouldn't be only one element: you will see the others if you type TAB instead of RET. IOW, the elisp-mode back-end does know about the other candidates, it just doesn't show them in *xref*. It somehow decided for me that I want only the exact match. And btw, there is another confusing difference between these back-ends that somehow bubbles up to the UI level: the elisp-mode back-end only supports finding multiple matches via completion, and completion, at least by default, only finds candidates whose leading substring matches what you type. By contrast, the *xref* buffer popped when the etags back-end is in use shows substring matches _anywhere_ in the symbol names, so it shows much more candidates.