From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#43709: minibuffer keybinding cheatsheet and launcher [CODE SUBMISSION] Date: Thu, 01 Oct 2020 12:04:45 -0400 Message-ID: References: <20200929165957.ibj67dnyaem6nezg@E15-2016.optimum.net> <20201001153147.3ucillviu62t2prf@E15-2016.optimum.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="11277"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 43709@debbugs.gnu.org To: Boruch Baum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 01 18:12:31 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 1kO1C2-0002nf-SD for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 18:12:31 +0200 Original-Received: from localhost ([::1]:55118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO1C1-0003C3-ON for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 12:12:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO14p-00039i-Ce for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 12:05:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54731) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kO14o-0007iR-22 for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 12:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kO14n-000678-Rs for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 12:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Oct 2020 16:05:01 +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.160156829823486 (code B ref 43709); Thu, 01 Oct 2020 16:05:01 +0000 Original-Received: (at 43709) by debbugs.gnu.org; 1 Oct 2020 16:04:58 +0000 Original-Received: from localhost ([127.0.0.1]:38044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO14j-00066i-BA for submit@debbugs.gnu.org; Thu, 01 Oct 2020 12:04:58 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO14g-00066R-E8 for 43709@debbugs.gnu.org; Thu, 01 Oct 2020 12:04:55 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B693780B9B; Thu, 1 Oct 2020 12:04:48 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A7DD58073F; Thu, 1 Oct 2020 12:04:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1601568286; bh=f0FxeC60RJV8tMI0FaD0VDRgFCV0jjlg45CH63Xrojk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=X3+4w0pB0PqdZrcraeA6sOFk8Ii2oVHB932Gbpoc+5ZGn3RM3slCCNqzN4w7x3xdU OUDY81sAKmpYRD3K/s/Zppeei00uX9yP+nr3vRPw1ychzNCJZbSI+4xdwKkN5JSuE7 yg8IufS2terJlbpiqQTOg89DpjoM8I+SEYfI6tGSGFQXTGBX98GC6A6w83dusz9guI UnwrJ5uLm72gZquSLwG8S73TRGy/ZzoIILC04ai7MWUNIAX+aJeiAL6sWUYcS/vCY1 VS1c5YVubsrT6/sojp5/TEgq2BnWH96Qllgdsl4ahooJG06UOTvhY2x9qhjjEB57xz 219VO9ollEwMw== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 42FA41202C5; Thu, 1 Oct 2020 12:04:46 -0400 (EDT) In-Reply-To: <20201001153147.3ucillviu62t2prf@E15-2016.optimum.net> (Boruch Baum's message of "Thu, 1 Oct 2020 11:31:47 -0400") 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:189525 Archived-At: >> [ To see why I say it's not quite ready, here's my experience with it: >> I just tried it in a fresh new Emacs session, and after `M-x >> key-assist` (which itself is a problem because most users won't >> know/bother to run this command way, so we'd need some more "obvious" >> way to run it) > Always a problem with a new feature. When you say 'obvious', you seem to > mean more than the normal publicizing of a new feature? I'm thinking that this would be useful for someone that not very familiar with Emacs, which also explains my further comments about the behavior. As it is, 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. 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 ;-) >> I get a prompt for something > You mean the prompt "Optional: Enter command regexp or keymap name:"? Yes. >> and without reading more the description I wouldn't know what the >> prompt wants > True of very many emacs commands. Not a justification though. It could > be a multi-line verbose explanatory prompt. 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, ...). > Reasonable. Could be argued both ways. I have no preference, and just > thought it friendlier this way to explicitly present to the user all the > options, especially since this is supposed to be a 'help' function. 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. >> and then it said "no choices found". > That's curious. I haven't seen that in my testing. What was your > response to the first prompt? RET > What was the value of 'major-mode' of the 'current-buffer' when you > ran the command? 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). >> 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 many > users can be expected to be using some non-default minibuffer completion > supplemental package (eg. ido, icicles, ivy), and those all have > slightly different behavior; many present a result-list without needing > 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. > Again, true of very many emacs commands. Not a justification though. I'm > not a regular on this list, but even slashdot.org is reporting that the > list has been discussing making emacs friendlier to new users, and I'm > on board with that, so I'll take any suggestions for improvement here, > but it might be better done as a patch to 'completing-read'. Ah, now that makes more sense. I thought you'd sent your package in the context of that discussion of improving the experience for novice users. >> I do think it would be nice to have something like it, since it's an >> alternative to the menus which has the advantage of being >> auto-constructed, doesn't need the mouse, and focuses on the keybindings. > Yep. Also, for me it was important that it present command descriptions, Agreed. > even if in the end it came at the expense of omitting command names to > make the strings shorter. That's a good tradeoff. >> It would also be nice to make it usable from minibuffers as well ;-) > Hmm, I wonder.. Maybe it already does programmatically on a per-case > basis. Interactively, do you mean integrating into the minibuffer > codebase? I've long wanted something like this for the minibuffer > options to isearch- I'm not sure exactly how it should do it. But yes, `isearch` is an obvious use case as well (I say "as well", because isearch doesn't actually use the minibuffer). >> > (while (not (setq choice >> > (cl-position >> > (substring-no-properties ; Is -no-properties necessary? >> > (completing-read prompt choices nil t)) >> > choices :test 'equal)))) >> >> Why do you have this loop? Doesn't the `require-match` arg of >> `completing-read` make it unnecessary? > > I remember thinking so, too, and then needing to add the loop because > completing-read was accepting a RET. My recollection is that it was > sending an empty string to cl-position. Ah, OK, that makes sense. > But besides all that, it's great, right? Yes, I like it, Stefan