From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Include which-key.el in the Emacs distribution Date: Tue, 15 Feb 2022 09:09:17 +1100 Message-ID: <87fsol9jsv.fsf@gmail.com> References: <20200908201434.hrvupafbu2kyvb4q@Ergus> <87wnhyk72h.fsf@posteo.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="11435"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.7; emacs 28.0.91 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 14 23:17:38 2022 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 1nJjf8-0002o6-6p for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Feb 2022 23:17:38 +0100 Original-Received: from localhost ([::1]:35568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nJjf6-0005ZF-Ae for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Feb 2022 17:17:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJjdH-0003WD-Ry for emacs-devel@gnu.org; Mon, 14 Feb 2022 17:15:43 -0500 Original-Received: from [2607:f8b0:4864:20::102f] (port=37581 helo=mail-pj1-x102f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nJjdG-00067S-70 for emacs-devel@gnu.org; Mon, 14 Feb 2022 17:15:43 -0500 Original-Received: by mail-pj1-x102f.google.com with SMTP id v5-20020a17090a4ec500b001b8b702df57so665028pjl.2 for ; Mon, 14 Feb 2022 14:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=QV6fpAF0p/2vsJlO5KaZUlgs/V77mQq9iCfiCZualtk=; b=Mjma0ARTCSfQfnxqgYBqq3ncmcXke3tnhz8GPKRk1HkK+XOrUha2g4/r1RjtAk0Zxy d6uwAj9OJ4gkduEf9WZVQtFXbl79WA0W6koGheR966TRCwg3ReedmNseXbBYfHY57rVH fnivrPtW0sGNZBjBmbkYBu6yonodZfwL4bIVZmrTK1RBreqVyMWcK7knuWJ9EkB84fui aIZX3lJdWM3bik8Xn6S+hbl2gbWRh86Xu86ojkMIcRtx9wbSdkYCU6QYvVfrCjn1gHj5 fQXAEwojUE/elJjlkZfmwSnOpq6h2pQmeK3iqmCF/kokg+xWO79hPcNLUyz+yhRCdCER iq4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=QV6fpAF0p/2vsJlO5KaZUlgs/V77mQq9iCfiCZualtk=; b=0N1XkaL9fj5t4yFKGrj0ANjl1mdx7n/KSqTMlck7wlR71rK2lI4yh1iApFTanf99xk icHIeXf3PCnhB3k1/XRXm3I+Q/9ODJjiRanRZ2bICfP6M9tHsAmMWL8Nzb0OfGn0NQpt DI6eaJXxYGIPOPOVs5aa4EVMhRmOf6oeB5v+IOnRkEGM4e0qJN4Z8TfMmGHKqDJsaYUW 1V9WeEZes116mQH4OMUmOjTv99RC5CvTzy/D9Hx/ak8ue07VUaJ89oI9lDkkGr7Ek05A iElYJcI4VCKq7XVpdvG9pstOR7JgM1nb1NXOcK3nNXhJzXWlhs2cc/p94m8t4tQ4rnMY ibVw== X-Gm-Message-State: AOAM531PsfxZLT6EqnkRZbZVm8Dl76dTD3CDz67tGA6E+vc0l3Rnpwje OP5NKM0LPz6Kn/ekd/R5qh2ml0KrAdk= X-Google-Smtp-Source: ABdhPJzVMCuhcthGtfKCp+EhUUwW6OhxkELTsy5nehI23neh+xPdLLn1omP1YdDVCnhw2RhZmo6YtQ== X-Received: by 2002:a17:902:d2d0:: with SMTP id n16mr908993plc.100.1644876940026; Mon, 14 Feb 2022 14:15:40 -0800 (PST) Original-Received: from dingbat (2001-44b8-31f2-bb00-a9bc-fef4-1eca-fd28.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:a9bc:fef4:1eca:fd28]) by smtp.gmail.com with ESMTPSA id lx5sm901190pjb.37.2022.02.14.14.15.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 14:15:39 -0800 (PST) In-reply-to: <87wnhyk72h.fsf@posteo.net> jj--text follows this line-- X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::102f (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::102f; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102f.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.635, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.devel:286302 Archived-At: Philip Kaludercic writes: > Corwin Brust writes: > >> On Tue, Sep 8, 2020 at 3:41 PM Stefan Kangas wrote: >>> >>> Ergus writes: >>> >>> > I really love which-key but enabling it by default for everyone could be >>> > a bit premature. Maybe adding a very easy to find option in the toolbar >>> > could be a better first step? >>> > >>> > So the ones (like me) who love it can improve it until it becomes ready >>> > to be default without the complains if the other who doesn't. >>> >>> Yes, we should definitely make any necessary improvements before >>> considering to make it the default. I believe that's what Stefan M was >>> also arguing, so I see no disagreement on that point. >>> >> >> Hi all. Having `which-key' available in core remains popular, at least on IRC. >> >> Now that it is available from GNU Elpa I wonder what is left to do and >> if there appears hope of including it with Emacs 29. > > My first question is why it should be added to the core, given that it > can be installed with a single command OOTB? My impression from using > (and seeing other people use) which-key would have me say that the UX it > provides goes contrary to the "style" that core functionality uses > traditionally (what other cases are there where not doing something > modifies the window configuration, the closes commonly used > functionality would be eldoc that displays information in the > minibuffer). > > What I would be more interested in is to add optional support for C-h to > continue a command prefix, so that if I want to know what keys a keymap > provides, I can request it immediately without waiting for the idle > timer to trigger a often too small popup window, without loosing the > partial input. Sounds like you would find Embark better than which-key. While Embark takes more effort to configure, it gives you very similar functionality as which-key, but provides a lot more and can provide powerful integration/enhancements for completion frameworks like vertico or selectrum.