From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: discoverability, better defaults and which-key in Emacs Date: Thu, 08 Feb 2024 18:50:25 +0200 Message-ID: <86il2yx5m6.fsf@gnu.org> References: <874jetaxri.fsf@jeremybryant.net> <87le84oqbd.fsf@yahoo.com> <87plxdpsxw.fsf@posteo.net> <87r0hridvr.fsf@posteo.net> <5dd3d04c-c0eb-43fe-b7c2-957f80261ea3@gutov.dev> <87eddqiw84.fsf@posteo.net> <32071337-c91d-46ad-bb9b-10b8d0c83965@gutov.dev> <86h6ikzc38.fsf@gnu.org> <1056a72d-af5c-487e-be33-67522fe47d17@gutov.dev> <87r0hnohgv.fsf@gmail.com> <86a5obxwy9.fsf@gnu.org> <61ffccc8-56c0-4b14-9420-2d0fd9cac216@gutov.dev> <86r0hnw1l1.fsf@gnu.org> <86o7crvza4.fsf@gnu.org> <941e2791-bb35-4de6-b7a7-e3dce4938a1d@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23927"; mail-complaints-to="usenet@ciao.gmane.io" Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org To: Dmitry Gutov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 08 17:51:37 2024 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 1rY7cf-0005yf-5g for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Feb 2024 17:51:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rY7be-0007vQ-Ss; Thu, 08 Feb 2024 11:50:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rY7bc-0007vA-NZ for emacs-devel@gnu.org; Thu, 08 Feb 2024 11:50:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rY7ba-0000cQ-El; Thu, 08 Feb 2024 11:50:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4BKlgcyOzj0zvdRKRtWbQU51dHGb+cTlhjj+ShnBQxw=; b=HNU2x+rgQ9p7 G5eJ950TjpLrzZFHjvkVU9XeNAwcq1ydLNRDe9PE6r5uInC9nOBQtOrQzRGnxkvFnEHK5hWgQo6bX v2CwQJgV4RV7qJ/msIUWe7l1zMSDNIr8DpIHBwuiLqNWs/+1Y8s33BjoLo4zhh386pf4on4K51Rs3 la6Xr3UTeIWk9HadHn/8wfWGRSDRVz6lsAiEEd/kPgkrgMx6JyJehQTlWxmX1htHS9mgWbpp6KUa0 oAZjJ52CmJSGABErN64Bbo0P0S6Wmbe5TIxcN8bqVpXrloD8VrLDOW8TbxqMEwy3HwS+hDV+TGRdT Hj0rq/1IBJ0kU5zA1xjosQ==; In-Reply-To: <941e2791-bb35-4de6-b7a7-e3dce4938a1d@gutov.dev> (message from Dmitry Gutov on Thu, 8 Feb 2024 16:43:41 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316040 Archived-At: > Date: Thu, 8 Feb 2024 16:43:41 +0200 > Cc: visuweshm@gmail.com, justin@burkett.cc, philipk@posteo.net, > luangruo@yahoo.com, jb@jeremybryant.net, emacs-devel@gnu.org > From: Dmitry Gutov > > >> If we consider the situations where C-h or f1 is rebound, having > >> misleading text in the message (with bindings that don't work) should > >> concern us as well. Even if one of the suggestions is likely to work > >> anyway (while the other doesn't). > > If you can come up with a code that detects at run time that help-key > > and/or F1 was rebound to a key that will not invoke > > describe-prefix-bindings, such a key should indeed better be removed > > from the message. But can we reliably do that? If we cannot, having > > two keys there instead of one is better. > > I think we should be able to, but since help-key doesn't call any > command directly through a map or fallback binding of some sort (instead > it's dispatched ad-hoc), the solution I have tried so far (also using > substitute-command-keys) did not help. Maybe Stefan (CC'ed) could have an idea. In general, since the key sequence was just echoed, we do know what sequence was typed, and can test whether adding help-char to it would produce a binding, like what we do in read_key_sequence where we decide whether to invoke prefix-help-command.