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: Wed, 24 Feb 2021 19:25:37 -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="30636"; 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 Thu Feb 25 02:27:22 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 1lF5R2-0007r8-Vy for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 02:27:20 +0100 Original-Received: from localhost ([::1]:36744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lF5R2-0002Jc-02 for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Feb 2021 20:27:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lF5PQ-0001R1-VZ for emacs-devel@gnu.org; Wed, 24 Feb 2021 20:25:41 -0500 Original-Received: from mail-pf1-f179.google.com ([209.85.210.179]:39511) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lF5PP-0008P7-9V for emacs-devel@gnu.org; Wed, 24 Feb 2021 20:25:40 -0500 Original-Received: by mail-pf1-f179.google.com with SMTP id u26so2521133pfn.6 for ; Wed, 24 Feb 2021 17:25:38 -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=3dCjXaWCTKEqCMoiXOKmLJm+dFhHkiIdtAo4HNCqCGM=; b=LFJK1fSoJjQKVvEnzbih/0Sg2Ls6h0llVBPKIHHWsjm1+lIxkLif8zO4iZ2yiANdg+ j7si7XCTkdl+ClKlg1d/iuviANeS4JGmU/TC6KUFXdA+z5RrN/M9+4bkawTYKEmea3G6 spycA0ZXLick1lvzSEKgxBBOLmHY9rf8+7D8WohTDwSH9eT/Wvwj0PWUs5RnpVaAcjMh 5tvFFfJJigdHTiUfnxPhy+ZblBwl7nE06OSPleeGI22HT5wuDbJfL9/n8mxrayrOtR3E ddJnoKNULP8x4sxvUop+tCIz69QLmyOJ9Abmq2rCnAObsSe4FE4EH4bV74FMuoU32XiH +2iw== X-Gm-Message-State: AOAM533ZWxUdl8HMqr+X8nnr8TNGgmfjuf7q2YfAgYqRrW8vSeJjMwLs VUiJYepCQEbUN9cqkbyT1wv+ub6hMIYbVDLD6lI= X-Google-Smtp-Source: ABdhPJxfBS5S9Xn9GN8uZZe4KkiSfmt54pIUzDV8bRH+Rpkho8QlHDaUAVnlbWvxzkW3Ugd9l3KgOKQdEjF7qagOnwc= X-Received: by 2002:a63:fd0a:: with SMTP id d10mr653270pgh.345.1614216337816; Wed, 24 Feb 2021 17:25:37 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Feb 2021 19:25:37 -0600 In-Reply-To: Received-SPF: pass client-ip=209.85.210.179; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f179.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:265597 Archived-At: Drew Adams writes: > What makes you think your highlighting is more > subtle? And more subtle than what? You just > said that you've never even tried help-fns+.el. OK, this is a fair point. I will try help-fns+.el. >> I also don't know of too many examples where >> links will be highly useful. > > Specifics, please. Show an example where a > `...' key link isn't useful. I actually meant what I wrote literally. So I would rather have hoped that you have some examples of where it is "highly useful". >> Still, I'm not writing off the idea completely, >> I just don't currently see how to balance the drawbacks. > > What drawbacks? So far, you've talked only > abstractly, about things that don't exist. I see two drawbacks: a) Too many links in the *Help* buffer that compete for attention. b) Not being able to show a consistent face in the minibuffer and the help buffer. (This is true iff we would use the `button' face also for linked keys in *Help*. Of course we could just not do that, but then we have an inconsistent face for the links instead...) >> 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. > > And yet that's what you've done with other parts > of help-fns+.el... Suit yourself. I assume you refer to `describe-keymap'? That work was very different in nature. My point is that it is not always as easy as just re-using some existing code. We still need to integrate it in Emacs. It is of course good that you offer your code for inclusion, but when you do so in general terms (rather than, say, as a patch) there is still quite some work remaining to make it happen. This was true for a highly isolated command like `describe-keymap', and even more so for the feature we discuss here.