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#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard Date: Mon, 4 May 2015 00:52:16 +0300 Message-ID: <55469890.20106@yandex.ru> References: <878ud6sjtt.fsf@gmail.com> <55463113.1090808@yandex.ru> <874mntsji3.fsf@gmail.com> <55465BDD.8080101@yandex.ru> <87zj5lqz2e.fsf@gmail.com> 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 1430690004 25871 80.91.229.3 (3 May 2015 21:53:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 May 2015 21:53:24 +0000 (UTC) Cc: Helmut Eller , 20487@debbugs.gnu.org To: Vitalie Spinu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 03 23:53: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 1Yp1p2-0003eU-8F for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 May 2015 23:53:12 +0200 Original-Received: from localhost ([::1]:60399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp1p1-000052-F9 for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 May 2015 17:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47109) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp1ox-00004t-Uz for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 17:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yp1os-0006zi-VX for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 17:53:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yp1os-0006zO-R5 for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 17:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yp1os-0007Sc-J9 for bug-gnu-emacs@gnu.org; Sun, 03 May 2015 17:53: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: Sun, 03 May 2015 21:53:02 +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.143068995028634 (code B ref 20487); Sun, 03 May 2015 21:53:02 +0000 Original-Received: (at 20487) by debbugs.gnu.org; 3 May 2015 21:52:30 +0000 Original-Received: from localhost ([127.0.0.1]:60996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yp1oL-0007Rl-FK for submit@debbugs.gnu.org; Sun, 03 May 2015 17:52:29 -0400 Original-Received: from mail-wi0-f171.google.com ([209.85.212.171]:33820) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yp1oJ-0007RX-AU for 20487@debbugs.gnu.org; Sun, 03 May 2015 17:52:27 -0400 Original-Received: by wicmx19 with SMTP id mx19so65286352wic.1 for <20487@debbugs.gnu.org>; Sun, 03 May 2015 14:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mMFUGE9FpeXVTV9TfEMIOpVKpObSp5cCx+jTfAYlSP4=; b=rQlqMSgO3S2vkfFX7vXX0zTHy217iikz1Il9eRgpTzRV884qZAeSnkuJDlYafpTpxo 902O0RrZjKAQ/b0HspDg3r4gd5LUWDTREepPCFp9UIRTddpjrGGieXtRWd8k+FpXhLxQ 2Tkzg3TA6CQzzFmOGFcrV5KAl6c3PxiYYJEKjKuzqzeCp2Lg7KAtcZhLAm3EsBpUhlYY 8oqowCFNybj75Wyyaabgt+1YUUuB5EAPEBx1JKfwzCXNekWaug06VVxhMEwlBxMnl3Lz x5vaHoVZOnwCA5jd5fLPwNqcJRQy7ymru+6SWf4MI+tuFOSOZn+xMIzolA9pUjijfX+w QdjA== X-Received: by 10.180.96.138 with SMTP id ds10mr13822318wib.95.1430689941710; Sun, 03 May 2015 14:52:21 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id u6sm17706518wjy.13.2015.05.03.14.52.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2015 14:52:21 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: <87zj5lqz2e.fsf@gmail.com> 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:102424 Archived-At: On 05/03/2015 09:46 PM, Vitalie Spinu wrote: > Colours and line number display should also be the same. There is no > much point to strain people to get used to different displays for the > same type of information. That's a good goal to strive for. > Currently file paths in *xref* are not highlighted with > compilation-info-face like grep and others do. For me files are bold and Okay, let's highlight all group headings this way for now. > items are also bold. So my whole buffer is in *bold*. This makes it > appear dirty and difficult to read. I think bold font should never be > used for large regions. I attach a sample. It wasn't bold for me (font-lock-keyword-face is apparently bold in your non-default theme). This one is harder, because *grep* leaves the line contents in the default face. I've done that too for now, but our text is clickable, whereas in *grep* you can only click on the file paths. That will need to be resolved. Line numbers are difficult for now, since they're simply a part of the description string. Maybe if we move them to a separate field. > I am using ack but still prefer grep output due to more efficient > vertical display. Personal preferences aside, I hope you can admit that the authors of modern-ish tools prefer the grouped display. > Note that grep, ack etc commonly need to output multiple occurrences per > file. With xref most of the symbols will have one-to-one correspondence > to the file. So it makes a lot of sense for *xref* to have file and > object on one line. I'm not sure why you've made that conclusion. It may be true for xref-find-definitions, but then the numbers of those results should be small anyway, so you're not running out of vertical space. In the xref-find-references output, on the other hand, you are likely to observe the opposite. Not just multiple matches per file, but even multiple matches per function (if we showed them). > Good example is helm-do-grep in which file names are abbreviated and are > not intrusive at all. Not every file name can be easily abbreviated. While you can compress the path down to what makes each segment unique (like the fish shell does in prompt), or even omit some, the segment names might by themselves be valuable to the user, on occasion.