From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#47012: xref copies keymap properties to minibuffer Date: Thu, 1 Apr 2021 04:16:08 +0300 Message-ID: References: <87czw9tnu9.fsf@mail.linkov.net> <3aad442a-7319-5db5-2fc6-560bb032c34d@yandex.ru> <87a6r9v24b.fsf@mail.linkov.net> <87sg4kb839.fsf@mail.linkov.net> <871rc3bls6.fsf@mail.linkov.net> <871rc2ly7x.fsf@mail.linkov.net> <4228b128-039c-2bcd-002c-5ac830d7a4d3@yandex.ru> <87pmzgtr80.fsf@mail.linkov.net> <186b46fa-3716-a76d-db85-09638d7805c7@yandex.ru> <87v99745jj.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="480"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Cc: 47012@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 01 03:17:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lRlxP-000AYl-Ag for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Apr 2021 03:17:11 +0200 Original-Received: from localhost ([::1]:39974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRlxN-0002Kx-R6 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 31 Mar 2021 21:17:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRlxG-0002Km-7c for bug-gnu-emacs@gnu.org; Wed, 31 Mar 2021 21:17:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44244) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lRlxF-0005FO-Vi for bug-gnu-emacs@gnu.org; Wed, 31 Mar 2021 21:17:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lRlxF-000680-QL for bug-gnu-emacs@gnu.org; Wed, 31 Mar 2021 21:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Apr 2021 01:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47012 X-GNU-PR-Package: emacs Original-Received: via spool by 47012-submit@debbugs.gnu.org id=B47012.161723977923500 (code B ref 47012); Thu, 01 Apr 2021 01:17:01 +0000 Original-Received: (at 47012) by debbugs.gnu.org; 1 Apr 2021 01:16:19 +0000 Original-Received: from localhost ([127.0.0.1]:55790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRlwZ-00066w-EK for submit@debbugs.gnu.org; Wed, 31 Mar 2021 21:16:19 -0400 Original-Received: from mail-ej1-f54.google.com ([209.85.218.54]:43957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRlwW-00066j-Nm for 47012@debbugs.gnu.org; Wed, 31 Mar 2021 21:16:17 -0400 Original-Received: by mail-ej1-f54.google.com with SMTP id l4so376516ejc.10 for <47012@debbugs.gnu.org>; Wed, 31 Mar 2021 18:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+Ku4+JZER32QVcxlbJkWTAoUlp4Uzg5fVgW5PL1oYcQ=; b=ctJfwDy+o8+SnYYwQ39TSsFlb8AgcuoD0nfQxOnJxNOWk2PfL1ETWVslJY6zzgYHBO IL53dgQ0f88VlFUPelXc00y2RCgzszkdB0E78B/cKLVN9gXL58ibB8FkXQ1GzAA3oLfJ V/ujydIodX749xyYuokqrTU8B1WvQre2jfSTPZys1fxRRVH73g3xoDR+crKNR0zWaRMg 5A+QEdtCaWSDAej5T8o/0OmR1CUe5W8fwEVtnjyqLhLBlPGuW+L2kLly7ebNR/f83fxK Iq5juIcedse5xU9UPAMMUsNW2R6oFtlchQFmLE5NXha7mjzlwVQy9LoHNn/SvO8fev0W 9gXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+Ku4+JZER32QVcxlbJkWTAoUlp4Uzg5fVgW5PL1oYcQ=; b=JWKU35ZIY/C4b3SZ96N2OvsvmnmE8wps01dEVhh34R/g5C9pHlEzIjOIt/8qAjWmWK 9fiCXRsiwxTGJ7n9XfCdeGB26TVssieaaD0pYKxuSIEdGSAhuLfKk/Gwi++qk6bE5D4Y 6yTREMpwtJn0W3+JueKrhcPVzFf52JUnp/WB7X6rItC8fyZQrDceLMUy9n4AxyICeQBR 6k+KoPApdGz1dxSkuqA7l09iJv1NkuKBOlSnMKqRbmMY9hZzwk+rOCVoai4NprvKCqAE YfYnR0nbuSdTaKVxtAw8+I5o1JcbbmCmLTr2fLuUFIDWMux80taS8YtSFF4esjqVj+D6 W2TQ== X-Gm-Message-State: AOAM5338FAw081kqhh0QeM6f/b3QOo1tHNKYr3psZn4qyOEPgfP3+cME ToghUMl7kPYqzT65LksvG/7T6ZivVr8= X-Google-Smtp-Source: ABdhPJxtUkbiMAAzAH4wY66kknRi0QBTRxsUx086vCIEaTkaSHcnK18z1/OjU6FdgttSdwci/plCxw== X-Received: by 2002:a17:907:d1f:: with SMTP id gn31mr6622614ejc.536.1617239770954; Wed, 31 Mar 2021 18:16:10 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id si7sm2069448ejb.84.2021.03.31.18.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Mar 2021 18:16:09 -0700 (PDT) In-Reply-To: <87v99745jj.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203400 Archived-At: 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).