GNU bug report logs -
#20487
25.0.50; Format and behavior of *xref* buffer is non-standard
Previous Next
Reported by: Vitalie Spinu <spinuvit <at> gmail.com>
Date: Sat, 2 May 2015 22:21:02 UTC
Severity: normal
Found in version 25.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
Message #14 received at 20487 <at> debbugs.gnu.org (full text, mbox):
On 05/03/2015 07:39 PM, Vitalie Spinu wrote:
> 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.
It has different uses. I'd probably also prefer if xref-find-apropos and
xref-find-references output buffers behaved like you're asking, though.
> 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.
Helmut, thoughts?
> I think if a new behavior is contentious the default should be
> consistent with how other similar modes behave.
Considering we can translate Grep output into data xref expects, we
could the latter the common UI. So, sooner or later, discussing better
defaults might be worthwhile.
> Are you questioning efficiency of *grep* displays?
Yes, obviously. Not to mention a lot of GUI applications, have you tried
Ack or Ag? They both use the grouped output by default.
> Repeated files have an advantage that you can immediately see which
> symbol is in what file.
I don't have any problems moving my eyes by a line or two to read it.
> No. My splits are horizontal.
That's odd. Assuming your files are 80 columns wide, and your windows
are tuned to that width, if the file name is printed on every line, it
would push the matched lines to the right, often leading to wrapping or
truncation.
In certain environments (like Java, where file paths are long), this can
be a bigger problem than in others.
> Well. Xref already has broken a bunch of emacs UI standards. I think
> this one is already one too many.
This one I'm feeling strongly about.
It's not like the handling of Grep output in Emacs was the result of
some big design. I bet that it simply was the easiest (while still
useful) one to implement in the command-line tool, and then when Emacs
integration was done, it was simpler to add highlighting and
clickability to it, instead of parsing and reformatting.
> 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.
Well, like I said, the output can be customizable. I'm sure some people
will appreciate if you implement the flat output.
> What's the problem more concretely? You can still display hierarchical
> information like this:
Yes, that doesn't look too bad. I somehow thought you'd want the method
name to be mentioned on each line, too, but there's no real need for
that. Good to know.
This bug report was last modified 9 years and 144 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.