From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Consistent face for keys in *Help* and `substitute-command-keys' Date: Wed, 10 Mar 2021 19:16:27 +0200 Organization: LINKOV.NET Message-ID: <874khjq6p8.fsf@mail.linkov.net> References: <83zgzsq7xn.fsf@gnu.org> <83v9afriqp.fsf@gnu.org> <83zgzjhvdn.fsf@gnu.org> <83a6rhxwah.fsf@gnu.org> <837dmlxspt.fsf@gnu.org> <834khpxr0s.fsf@gnu.org> <8335x8ybw9.fsf@gnu.org> <87czwageno.fsf@mail.linkov.net> <878s6xwngp.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40255"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 10 18:38:29 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lK2my-000ALR-8K for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 18:38:28 +0100 Original-Received: from localhost ([::1]:48782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lK2mx-0003GQ-8q for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Mar 2021 12:38:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK2U5-0001q5-3q for emacs-devel@gnu.org; Wed, 10 Mar 2021 12:18:57 -0500 Original-Received: from relay10.mail.gandi.net ([217.70.178.230]:57137) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK2U2-0004Bt-OA; Wed, 10 Mar 2021 12:18:56 -0500 Original-Received: from mail.gandi.net (m91-129-108-46.cust.tele2.ee [91.129.108.46]) (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 497EE240009; Wed, 10 Mar 2021 17:18:49 +0000 (UTC) In-Reply-To: (Stefan Kangas's message of "Tue, 9 Mar 2021 17:38:12 -0800") Received-SPF: pass client-ip=217.70.178.230; envelope-from=juri@linkov.net; helo=relay10.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266287 Archived-At: >> I completely agree. I retained "grey85" that was used for foreground, >> but it's not suitable for background. But OTOH, "grey95" is almost >> indistinguishable from the default white background. > > The change is fine, but I have a nit/question: > > On my screen grey95 is clearly distinguishable while grey90 is too dark > for comfort. You report something quite different from that, which > makes me think that this is perhaps not simply down to taste or > mere subjective opinion. When the contrast with the default background is too low, then users will miss the highlighting, so when the user doesn't see that it has a different color then it will look as if there is no highlighting at all. But when it's slightly darker, then I see no problem for users. So it seems better to have a slightly darker color than to let users miss highlighting. To decide what would be a good default, you need to take into accounts opinions of the majority of users, but also possible problems that the default could cause to the minority of users. > Could this be associated with things like differences in luminosity of > our physical monitors, brightness/contrast settings, X gamma settings > and what have you? Maybe, I tried grey95, but when the prompt us at the bottom of the screen: foo changed on disk; really edit the buffer? (y, n, r or C-h) highlighting of single letters is indistinguishable from the background. > Is there a way to find an objective measure to decide the better default > here? Or should we just make both of us slightly (un)?happy by setting > the color to e.g. grey92, assuming that the mean between our findings is > the most scientific we can hope to get and will work somewhat okay-ish > everywhere, and call it a day? With grey92 the situation is slightly better. >> GitHub and GitLab use "grey90" for light and "grey25" for dark, >> so I changed now accordingly. > > BTW, where do you find "grey90"? They seem to use a lighter background > than that on the pages I've been looking at. I deduced this color approximately because on github repos shades of gray are achieved using transparency. > Here I see #fafbfc for keys, which is between gray98 and gray99, with an > added outline: > > https://docs.github.com/en/github/getting-started-with-github/keyboard-shortcuts Indeed, with a border, it's hard to miss highlighting. > Here I see #f0f0f0 for keys, which is gray94, with no added outline: > > https://docs.gitlab.com/ee/user/shortcuts.html Here there is no border, so they need to use darker colors, darker than gray95. So please decide what the default color would be more preferable: with a border a lighter color could be used, without a border a darker is needed. >> When trying to use the style :background "grey90" >> :box (:line-width 2 :style released-button) >> the look is much nicer, but at the cost of wasting more vertical space >> for higher lines. > > The look of that is not too bad. It looks slightly dated perhaps (the > latest trend is to keep things flat rather than fake 3D) but at least it > is extremely clear. It is arguably a more user-friendly choice. Then it's possible to use flat with rounded borders, without 3D effect. > I'm not sure that I notice any wasted vertical pixels (we are talking 1 > or 2 of them or something like that, right?) but I didn't measure it. 2 pixels (top and bottom) for line-width 1, 4 pixels for line-width 2. Especially undesirable when this will increase the height of the minibuffer.