unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Vitalie Spinu <spinuvit@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
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: Sun, 03 May 2015 20:46:17 +0200	[thread overview]
Message-ID: <87zj5lqz2e.fsf@gmail.com> (raw)
In-Reply-To: <55465BDD.8080101@yandex.ru> (Dmitry Gutov's message of "Sun, 3 May 2015 20:33:17 +0300")

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

 >>> Dmitry Gutov on Sun, 3 May 2015 20:33:17 +0300 wrote:

 > On 05/03/2015 07:39 PM, Vitalie Spinu wrote:

 > 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.

I would be happy with that. As long as all buffers looks the same, have
same UI and use space wisely.

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.

Currently file paths in *xref* are not highlighted with
compilation-info-face like grep and others do. For me files are bold and
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.


 >> 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.

I am using ack but still prefer grep output due to more efficient
vertical 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.

 >> No. My splits are horizontal.

 > That's odd. Assuming your files are 80 columns wide, 

Right. Long file names are indeed a problem. An inconvenience which I
will get down to eventually if no one else does before me.

Good example is helm-do-grep in which file names are abbreviated and are
not intrusive at all.

  Vitalie



[-- Attachment #2: xref1.png --]
[-- Type: image/png, Size: 15018 bytes --]

  parent reply	other threads:[~2015-05-03 18:46 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 [this message]
2015-05-03 21:52         ` Dmitry Gutov
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=87zj5lqz2e.fsf@gmail.com \
    --to=spinuvit@gmail.com \
    --cc=20487@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=eller.helmut@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).