From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: RE: [External] : Consistent face for keys in *Help* and `substitute-command-keys' Date: Tue, 23 Feb 2021 22:44:49 -0600 Message-ID: References: <87h7m5iagw.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17981"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Drew Adams , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 24 05:45:42 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 1lEm3S-0004aw-02 for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Feb 2021 05:45:42 +0100 Original-Received: from localhost ([::1]:46356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lEm3R-0002HU-2m for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Feb 2021 23:45:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lEm2f-0001qE-Bn for emacs-devel@gnu.org; Tue, 23 Feb 2021 23:44:53 -0500 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:46972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lEm2d-00021w-F7 for emacs-devel@gnu.org; Tue, 23 Feb 2021 23:44:53 -0500 Original-Received: by mail-pg1-f173.google.com with SMTP id h4so650867pgf.13 for ; Tue, 23 Feb 2021 20:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=HPMcIk7YPc786CUyl3I958ZoLwGJNofoZXkmvx4UuYc=; b=e7VAhd++Eb+KZSITxEH6mVR6gYXEoD6UbjuB7x/I8cMI1G7GXJlJKXXTvNaL1KKUgw I/QDvRcfmVegJg34hDlOdaOnxcGMh8/47uefrOZ9L2YpCWquMRy9i9w7IhkL9X1jXkus FeMGeDQIfCLPL7LjfCupmFtXVIEKfiBV12LcJgwsVOI0RyyyEpiS5UEyyqMO/VxqIKdg YXKQC4Pm7z9qfm45damPLunyz282gCEbPTfzhUcw1NGBbRsp6Wwc54I0IDvCL9FAlOML 5Xt9Yg42GK1P4EQYdq0jTlu5Tl56+mcnId/MZlnlaA/Xx5ErWgdy+4jzat+se3Dce3py pW6w== X-Gm-Message-State: AOAM530Jk4Nja4FlqmJ6hOxWUfPpHhSKDxbTQt9tiFpxOlF3nNNZXjOO elmmQLvRmabasOMK/Ayeehcf9ZdobEf+irHCR64= X-Google-Smtp-Source: ABdhPJzR8ItPsM/yvJsyjXnTCBSGiEmVHCNhsI8euBvENsfrnbiZLss4BSBAkCqwEND5L5V7OZ/k3XEoID9IXdv3M/A= X-Received: by 2002:aa7:8889:0:b029:1ed:f38:4438 with SMTP id z9-20020aa788890000b02901ed0f384438mr27702206pfe.44.1614141889809; Tue, 23 Feb 2021 20:44:49 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Feb 2021 22:44:49 -0600 In-Reply-To: Received-SPF: pass client-ip=209.85.215.173; envelope-from=stefankangas@gmail.com; helo=mail-pg1-f173.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:265564 Archived-At: Drew Adams writes: > I think you already knew that I've been doing this > in help-fns+.el for over a decade. I've offered > the code before, and we've discussed it. It uses > `help-substitute-command-keys': I admit that I have never used any of your libraries. But I have seen Bug#8951 and the code you presented there. > That is, keys are linked to their commands. > So their face is the face Emacs uses for links. > > I think that's the right (better) approach. I'm not convinced of that. There will be many links all over the place, sometimes many links to the same place. It risks cluttering the help screen too much, whereas the effect you see with my patch is more subtle. I also don't know of too many examples where links will be highly useful. Still, I'm not writing off the idea completely, I just don't currently see how to balance the drawbacks. >> Having looked over the 430 matches for s-c-k in our tree, I couldn't >> find any location where we would not benefit from this consistency. On >> the contrary, it would be quite nice to see that the same face used in >> *Help* also shows up in messages such as these: >> >> "Use \\[shadow-copy-files] to update shadows." >> "Press \\[wdired-finish-edit] when finished or \\[wdired-abort- >> changes] ..." >> "\\[scroll-up] scrolls up, \\[scroll-down] scrolls down, ..." >> >> Please find attached a patch. It is a little bit rough around the >> edges still so needs polishing up and documentation. For testing, >> try e.g. `C-h C-h', `C-h C-h', `C-h C-c', or even `C-s C-h ?'. > > That's already been solved. Care to elaborate? AFAICT, messages do not currently display keybindings in a different face. > You can start with the code in help-fns+.el. > Or you can start from scratch. But DTRT. The work is mostly to identify the places where we output keys and ensure the strings get the correct face properties applied to them. Therefore, it is unfortunately not much help to start from anything that is not the Emacs source code or a patch to the Emacs source code.