From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Boruch Baum Newsgroups: gmane.emacs.bugs Subject: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE SUBMISSION] Date: Thu, 1 Oct 2020 16:46:17 -0400 Message-ID: <20201001204617.qbpxwnyoqlckjgsl@E15-2016.optimum.net> References: <20200929165957.ibj67dnyaem6nezg@E15-2016.optimum.net> <20201001153147.3ucillviu62t2prf@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27278"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: NeoMutt/20180716 Cc: 43709@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 01 22:47:44 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kO5UN-0006yu-Vx for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 22:47:44 +0200 Original-Received: from localhost ([::1]:52560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO5UM-0004Jz-OQ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 16:47:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO5Ti-0004HC-Ix for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55238) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kO5Ti-0003z8-9U for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kO5Ti-0000mW-6v for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Boruch Baum Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Oct 2020 20:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43709 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 43709-submit@debbugs.gnu.org id=B43709.16015851942970 (code B ref 43709); Thu, 01 Oct 2020 20:47:02 +0000 Original-Received: (at 43709) by debbugs.gnu.org; 1 Oct 2020 20:46:34 +0000 Original-Received: from localhost ([127.0.0.1]:38551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO5TF-0000lp-Jd for submit@debbugs.gnu.org; Thu, 01 Oct 2020 16:46:33 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:55515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO5TC-0000la-Ck for 43709@debbugs.gnu.org; Thu, 01 Oct 2020 16:46:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601585181; bh=rvWnc8vGNewk4O8Qr12xl0Yql8cQt/8DPyqiw3jmkCY=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=gVyuxxcunwhNaZmGjNs1Ktxh30L8qoC7NpCyFZnsQGXUJo1pFII3HjX2858tdJW8e mpfZ+oET5YgWolatVL9u2PjM8YSen17/9Xx1DjawLUlzX1Lusbw9Ka+qs37ACndXyc CaqZx1nFVLTu1cps6j2IGHa7jvniYq0EaqRKiXA4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from E15-2016.optimum.net ([72.89.170.172]) by mail.gmx.com (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1M5QFB-1kNGeX2t9B-001NIz; Thu, 01 Oct 2020 22:46:21 +0200 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:KngoGShS0gAT1EETsB7YWiOHV3+8olcavt60iEjI3gyGc2buBpb Z6tgsZdaY4FJuM5CaZual7qeG/jypIwDwc1SAEKZ7ORBDkdlCAdU8Lxb7ZapyLZWkdO5C7r jP7C60cin/ZoPufjaPdHsGDm3bPkOr3c5NxTwTH98Vt6a4E86IMqQ76TWbQ4a0MI1xESxE/ GQPt05aUKC5mGdJvYK61Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:8rKNQDIWGYo=:W9dlvnwzVSe5lZEPUYPS/D ZY/OwFWL0UYix/2Cijt1kvoT6HtTsmzUUcQf5fUfW2FuJwxSr0cZpm1qEMXRPrNz+WP+Eb88T pLrd+bIKUkBjk7F1/awivCLe4CnJsZuiulpXR6GiM+8zftqDY5bvluBp94QVfCgec7ex/aS30 gm7PpCnFkviWvNMndNmpXKgqQRy8pBqivST/ONhwNpeMikI+abT92jsRorH6twP3X5GTNe9Bo qo3LNR0XYsT8pz9yrmINBw+Wh9bNLkkLOVrcgQPZpmKO/Bm2z2zmJSyW/XbjFFXX9/OaXgwHl +KLtcWq3bhEMV7gLJR5w6gQnOZeBieeTGv9mw1GuTpFp1aZIG2ghGwFd4MLj2l324H0EX9CbG ez5Rtjqb5JypMyaExJfBzWC2lKrV5jJ0agcNa2EthUK1l3W65CCvR3ZLUViJpLgte7VDyCjmf ofv4K336letvWU2R1xhKqwkokvWM2PyrZkDDTtx/ONc+4//5mlJMbNKIUyGhT+TVc0jZkFgWN 0349lnfnpeXhKSh6cjEO8Qz2X2dYaKVLBwu/pYmJLiTxf5a6pP5ovWPfR1LEupRJ9kQ0Sqmxt 72Z1XgBaSvWqkxCVuDYh4XAACLXIEwNxBr2wT0wzL//LgGmViL9d9ZAg+Kkm3i4QPkzqI8gYY YCnWdIYMiiJMuaKwmhkTfW2ShGxg6KBT/58UzG3zBTi4w7N+6aRejRnziByTKZKgM1tXGRTbg J2mmR0fcSKRC7W5xHft/HMgHivvf3kBOmrBhC9NJUqAJ2b1kdbZgM8s/DfkcNNdqTe7ra3bC X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189587 Archived-At: On 2020-10-01 12:04, Stefan Monnier wrote: > I'm thinking that this would be useful for someone that not very > familiar with Emacs, It could be, yes. > it seems instead geared toward users that are already familiar with > Emacs and want to get to know some new mode or something like that. True. > For a novice, we'd ideally want the user to be able to find and use this > functionality "naturally" without even knowing beforehand how to look > for it and how Emacs generally works ;-) Oh, emacs. I'm the wrong person to ask because my reflexive response was to assume everyone should expect something like 'C-u C-h k'. BTW, a few months (years?) ago I had an email exchange with Eli Zaretskii in which he mentioned the help feature that he felt was most useful and important ... and it turned out not to even have a keybinding o even a mention in 'C-h ?' (and now I've forgotten even what it was the command was...) > I think skipping the prompt is an easier way to avoid the confusion. > Only prompt if the user asks for it (e.g. with a `C-u` prefix, an > alternative entry-point, ...). My initial inclination was to go for the prefix-arg option, but that wouldn't be friendly to novice users. And then I thought the same thing about an alternative entry-point, because it's asking someone to remember two separate commands. If the goal is to deal with the confusion of novices, the way to do it is with a single command and verbose interface. Even for non-novices, the goal here is to reduce the requirement to memorize, so having multiple ways of invoking the command is contradictory in that it asks for more memorization. A golden mean would be to come up with a short and clear prompt that can be ignored for most cases. > Or maybe we'd want to offer this prompt *afterwards*, as a special > command to change&recompute the completion table based on > a new criterion. Not difficult to program, but when I think about it, I see two obstacles: 1) The prompt ends up being at least as messy or confusing. What I end up with is a three-line prompt, something like (example being a dired buffer): Presenting list of 'dired-' commands. Select an item on the current list, or to present a list using a different regexp 2) What could you use to guarantee no conflict with any other entry on the list? Remember that we're inside 'completing-read' at this point, so we can't be using control characters, can we? Even if we can dynamically change the based upon a uniqueness check of all characters in the list, that would just add to confusion, because each different invocation would generate a different . In practice, it would be difficult to generate such a unique key because completing-read matches against all characters in list, which in our case includes all characters in the description, not just those of the keybindings. > >> and then it said "no choices found". > I was in *scratch*, so should have been `lisp-interaction-mode`. > Maybe the "no choices found" message should mention the search string > that was used (that's also a good way to teach the user what the first > prompt means). Agreed. I'll work on it. My preference would then be for a verbose minibuffer message, maybe as much as three long lines, amounting to a mini-tutorial, the goal being to reduce confusion for novices or people unfamiliar with the operation. > >> So I tried again in a dired buffer, where it instead showed me a > >> minibuffer prompt "Select: " with no indication of what it is I > >> should be selecting, > > > > I had difficulty deciding what text to use for this prompt because man= y > > users can be expected to be using some non-default minibuffer completi= on > > supplemental package (eg. ido, icicles, ivy), and those all have > > slightly different behavior; many present a result-list without needin= g > > to TAB. > > Good point. For the plain old default, it would make a lot of sense to > eagerly popup the *Completions*, but I'm not sure how we could do it > without getting in the way for ivy and friends. Is this again something to consider implementing as a patch inside completing-read, ie. change the message/prompt inside completing-read; would users of the packages that commandeer the mini-buffer interface ("ivy and friends") see the completing-read prompt at that point? At that point, they've already commandeered the interface. =2D- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0