unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: Helmut Eller <eller.helmut@gmail.com>, 20487@debbugs.gnu.org
Subject: bug#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard
Date: Mon, 4 May 2015 00:52:16 +0300	[thread overview]
Message-ID: <55469890.20106@yandex.ru> (raw)
In-Reply-To: <87zj5lqz2e.fsf@gmail.com>

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.





  reply	other threads:[~2015-05-03 21:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02 22:20 bug#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard Vitalie Spinu
2015-05-03 14:30 ` Dmitry Gutov
2015-05-03 16:39   ` Vitalie Spinu
2015-05-03 17:33     ` Dmitry Gutov
2015-05-03 17:36       ` Dmitry Gutov
2015-05-03 18:46       ` Vitalie Spinu
2015-05-03 21:52         ` Dmitry Gutov [this message]
2015-05-03 22:20           ` Vitalie Spinu
2015-05-04  2:24             ` Dmitry Gutov
2015-05-03 20:05       ` Hielmut Eller
2015-05-03 20:30         ` Vitalie Spinu
2015-05-03 20:48           ` Dmitry Gutov
2015-05-03 21:49             ` Vitalie Spinu
2016-02-21 23:07               ` Dmitry Gutov
2015-05-04  2:18     ` Stefan Monnier
2015-05-04  2:29       ` Dmitry Gutov
2015-05-04 11:15         ` Vitalie Spinu
2015-05-04 11:19           ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55469890.20106@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=20487@debbugs.gnu.org \
    --cc=eller.helmut@gmail.com \
    --cc=spinuvit@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).