unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 47012@debbugs.gnu.org
Subject: bug#47012: xref copies keymap properties to minibuffer
Date: Thu, 1 Apr 2021 04:16:08 +0300	[thread overview]
Message-ID: <b04842f2-5666-29d1-c4fa-0902c26400aa@yandex.ru> (raw)
In-Reply-To: <87v99745jj.fsf@mail.linkov.net>

On 31.03.2021 20:05, Juri Linkov wrote:
>>>    -(defface xref-file-header '((t :inherit compilation-info))
>>> +(defface xref-file-header '((t :background "grey90" :extend t))
>>>      "Face used to highlight file header in the xref buffer."
>>>      :version "27.1")
>>> #+end_src
>>
>> I'm not sure I like the result. Simply applying your change to the face
>> results in a color-less buffer with grey spots for both file headers and
> 
> It's good that the buffer is color-less since this improves readability
> because in such cases colors add distraction.

But colors add emphasis as well, don't they? If something is written in 
a different color, that makes it stand out. Use too many colors - we get 
into the "angry fruit said" territory, but use too few, and you're 
leaving some tools on the table.

>> match highlights (at least, with my current theme).
> 
> Indeed, it adds grey lines for file headers, but there are
> no grey lines for match highlights by default.

Fair point, I've tried your proposal again with the default theme.

Highlighting color is not grey, so there's less of that color-less 
impression. The headers still get uncomfortably dark, kinda lifeless. I 
don't get the same impression in diff-mode buffers.

And in diff-mode buffers there is a lot of grey background near and 
around the file names already. So making their background a darker grey 
doesn't take away much from readability while providing the needed 
emphasis. And the color green is not an option there.

>> It's less of a problem with diff-mode because its basic background is
>> grey already.
> 
> The proposed change is for the default theme.
> If the proposed change doesn't fit your personal theme customization,
> this is fine.  At least, please mention in the docstring a suggestion
> how the users could improve the readability of this face.

The above is a comparison with another core package.

I'm fairly sure your suggestion is not going to improve readability, 
though it certainly does make lines with file names stand out more.

A carefully worded recommendation wouldn't hurt, but I wonder what would 
be the best place for it.

>> Then I've tried to see what others do, for instance
>> https://github.com/Wilfred/deadgrep, which I'd heard people praise
>> usability of.
>>
>> The only distinction it adds to file names is "bold :t". And diff-mode also
>> does that, actually.
>>
>> So... how do you like this simple change?
>>
>> (defface xref-file-header '((t :bold t :inherit compilation-info))
>>    "Face used to highlight file header in the xref buffer."
>>    :version "27.1")
> 
> This is exactly what I used as customization for a long time,
> and it was a pain with so much of "visual garbage", until I realized
> there is the existing solution in diff-mode faces.

The above was actually a mistake on my part, because the default theme 
already puts ':bold t' on the 'success' face, which is in turn inherited 
by 'compilation-info' and 'xref-file-header'. Thus my suggestion was a 
no-op.

Could you elaborate on the "visual garbage" part? If you mean the use of 
colors, then the default theme is not too shy about having bright 
colors. So at least that is consistent with other looks.

> It seems you're inclined to keep the green color because this is what
> is used in grep, right?  But in grep, the green color on file names
> doesn't add distraction because file names are located on the left,
> whereas matches are on the right part of the output.  But in xref output
> lines with file names and lines with matches are interlaced.

But it does create an analogy with Grep, which is one of the main places 
where we're used to seeing file names in a list. Thus looking at the 
green color we're likely to make a connection and see that this line 
shows a file name.

I'm not as much beholden to this color exactly, as to the idea of using 
*some* color for this purpose. And I don't know of better prior art.

Regarding file names on the left, Grep does that, but look at ripgrep in 
the console, or the deadgrep Emacs package. Neither add any extra 
decorations to the line except emphasizing it with a different color 
(admittedly not green in these two cases) and (maybe) bold font weight.

Or look at ack or SilverSearcher, which both use green for file names, 
while using the same grouping layout that we do (they had been an 
inspiration, even though we've inherited the xref UI from SLIME):

https://altbox.dev/ack/screenshot.png
https://spinorlab.wordpress.com/2015/08/15/the-silver-searcher/

> Another suggestion how to remove "visual garbage" is to truncate
> duplicate prefixes: currently the prefixes of long absolute file names
> are repeated for all file names.  It would improve readability
> to display shorter relative file names without duplicate project root part.

Please try (setq xref-file-name-display 'project-relative).





  reply	other threads:[~2021-04-01  1:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08 20:03 bug#47012: xref copies keymap properties to minibuffer Juri Linkov
2021-03-09  2:08 ` Dmitry Gutov
2021-03-11 20:58   ` Juri Linkov
2021-03-24 20:38     ` Juri Linkov
2021-03-24 21:57       ` Dmitry Gutov
2021-03-25  9:40         ` Juri Linkov
2021-03-25 10:57           ` Dmitry Gutov
2021-03-25 21:28             ` Juri Linkov
2021-03-25 22:12               ` Dmitry Gutov
2021-03-30 19:16                 ` Juri Linkov
2021-03-31 15:47                   ` Dmitry Gutov
2021-03-31 15:59                     ` Eli Zaretskii
2021-03-31 16:10                       ` Dmitry Gutov
2021-03-31 16:57                         ` Eli Zaretskii
2021-04-01  0:25                           ` Dmitry Gutov
2021-04-01  7:17                             ` Eli Zaretskii
2021-03-31 17:05                     ` Juri Linkov
2021-04-01  1:16                       ` Dmitry Gutov [this message]
2021-04-01  8:43                         ` Juri Linkov
2021-04-01 14:13                           ` Dmitry Gutov
2021-04-01 18:45                             ` Juri Linkov
2021-04-01 19:06                               ` Eli Zaretskii
2021-04-01 21:28                                 ` Dmitry Gutov
2021-04-02  6:08                                   ` Eli Zaretskii
2021-04-02 23:50                                     ` Dmitry Gutov
2021-04-03  7:24                                       ` Eli Zaretskii
2021-04-03 18:12                                         ` Dmitry Gutov
2021-04-03 18:19                                           ` Eli Zaretskii
2021-04-02  8:20                                 ` Juri Linkov
2021-04-01 22:43                               ` Dmitry Gutov
2021-04-02  8:25                                 ` Juri Linkov
2021-04-02 23:23                                   ` Dmitry Gutov
2021-04-04 22:55                                     ` Juri Linkov
2021-04-05  2:15                                       ` 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=b04842f2-5666-29d1-c4fa-0902c26400aa@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=47012@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /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).