From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.bugs Subject: bug#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard Date: Sun, 03 May 2015 18:39:32 +0200 Message-ID: <874mntsji3.fsf@gmail.com> References: <878ud6sjtt.fsf@gmail.com> <55463113.1090808@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430671223 8369 80.91.229.3 (3 May 2015 16:40:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 May 2015 16:40:23 +0000 (UTC) Cc: 20487@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 03 18:40:14 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 1Yoww9-0008Tp-L2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 May 2015 18:40:13 +0200 Original-Received: from localhost ([::1]:59776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yoww8-0001QO-Oo for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 May 2015 12:40:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yoww5-0001Oj-05 for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 12:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yowvz-0002LC-Vy for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 12:40:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yowvz-0002Kj-Tf for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 12:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yowvz-0006AC-ET for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 12:40:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vitalie Spinu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2015 16:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20487 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20487-submit@debbugs.gnu.org id=B20487.143067118423661 (code B ref 20487); Sun, 03 May 2015 16:40:03 +0000 Original-Received: (at 20487) by debbugs.gnu.org; 3 May 2015 16:39:44 +0000 Original-Received: from localhost ([127.0.0.1]:60870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yowvf-00069Y-Jm for submit@debbugs.gnu.org; Sun, 03 May 2015 12:39:44 -0400 Original-Received: from mail-wg0-f44.google.com ([74.125.82.44]:36697) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yowvd-00069I-1B for 20487@debbugs.gnu.org; Sun, 03 May 2015 12:39:41 -0400 Original-Received: by wgen6 with SMTP id n6so130167141wge.3 for <20487@debbugs.gnu.org>; Sun, 03 May 2015 09:39:34 -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=uupgZ/HXWNYTqVEs2mh6eyikJdM+14S/d5EA899M6ew=; b=Qt6EElBchuf+MwVLMZ2o/wGhoFXz5Q/CM6ca5AnhsHiXqRt5jU3VFMhkoVP5c2W94i flFlvdYDznfmbXDYcZAeUpclJ0wQjzGR2JYm1B63IIMUL7uSWJ/J5+YoV6y5sb1d5vra NcSmTDAkbYxwM0JsUtxwFEgUZQU2lwLGUjHmpEZx9eV/tSp4a/cnkZH5OXcOCG76nY1v 9cmJiCQpRgYFEZmnz4Fp1tYTdp6k6LLzd1mA7xgsvn5w6EV8mB8vVOOOTgRARt3ZRiAT K3CS4L4Fess5KL5mLCXFvxek9UxDin3FX4UNJA/MnFHYCdUZsPStI3CcFqHnxokZvLOU Xbrw== X-Received: by 10.194.121.163 with SMTP id ll3mr25551155wjb.142.1430671174189; Sun, 03 May 2015 09:39:34 -0700 (PDT) Original-Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id e10sm7290018wij.11.2015.05.03.09.39.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2015 09:39:32 -0700 (PDT) In-Reply-To: <55463113.1090808@yandex.ru> (Dmitry Gutov's message of "Sun, 3 May 2015 17:30:43 +0300") 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:102406 Archived-At: >>> Dmitry Gutov on Sun, 3 May 2015 17:30:43 +0300 wrote: > On 05/03/2015 01:20 AM, Vitalie Spinu wrote: >> - on RET *xref* is buried. That's not that other modes do and it's >> rather inconvenient IMO. > That's valid complaint, but it's very convenient to bury the xref buffer upon > jumping to a location, Not for me. Now I am using xref for what I would normally use grep before - locate stuff around and familiarize myself with the code. So I would like to keep it open. > Further, on more than one occasion I needed to only jump to one location in > *grep* and *compile* buffers, preferably in the same window, in order to hide > the said *grep* or *compile* buffer. We don't have an easy way to do that. I never have problems with that. Emacs pops buffers in a variety of ways but rarely hides them. I think people are used to manage their own buffers as they see fit. I don't think xref should "help" them with that. Systems like HELM have their own consistent but different dynamics. I would really leave hiding buffers to HELM on this occasion. > I'd welcome suggestions taking this into account. I think if a new behavior is contentious the default should be consistent with how other similar modes behave. >> I would rather prefer the way *grep* does that. > So, you'd call displaying the same file name over and over for each > location inside it, "efficient"? Are you questioning efficiency of *grep* displays? I like the files being repeated. but that's not quite my point. I want xref to place symbol description on the same line with the file (as other modes do). Repeated files have an advantage that you can immediately see which symbol is in what file. > Do you favor vertical splits? No. My splits are horizontal. > Someone can implement a different rendering method for xref buffer > (and set xref-show-xrefs-function to it), but I'm against making it > default. Well. Xref already has broken a bunch of emacs UI standards. I think this one is already one too many. You can go against Emacs conventions but you cannot go against unix world. You cannot change how grep outputs stuff in terminal. People are used to standard displays and new mode better be considerate of that. > That rendering method will also encounter difficulties if xref groups > will sometimes have 2 levels of nesting (or more?). What's the problem more concretely? You can still display hierarchical information like this: file1:23: Class foo file1:25: -- Method boo { some more stuff her } file1:26: -- Method baz file2:70: Class foo Vitalie