bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard


From: Dmitry Gutov
Subject: bug#20487: 25.0.50; Format and behavior of *xref* buffer is non-standard
Date: Mon, 4 May 2015 00:52:16 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]