From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#60527: 30.0.50; Typing SPC in a minibuffer with completion Date: Wed, 4 Jan 2023 11:11:40 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28322"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Monnier , 60527@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 04 20:12:16 2023 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 1pD9BQ-0007FE-42 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 Jan 2023 20:12:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pD9BF-00089E-Fm; Wed, 04 Jan 2023 14:12:06 -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 1pD9BD-00087w-1N for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 14:12:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pD9BC-0005Vy-BT for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 14:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pD9BB-0007TS-Kz for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 14:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Jan 2023 19:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60527 X-GNU-PR-Package: emacs Original-Received: via spool by 60527-submit@debbugs.gnu.org id=B60527.167285950728709 (code B ref 60527); Wed, 04 Jan 2023 19:12:01 +0000 Original-Received: (at 60527) by debbugs.gnu.org; 4 Jan 2023 19:11:47 +0000 Original-Received: from localhost ([127.0.0.1]:49624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pD9Ax-0007Sz-4E for submit@debbugs.gnu.org; Wed, 04 Jan 2023 14:11:47 -0500 Original-Received: from mail-pf1-f172.google.com ([209.85.210.172]:34523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pD9Av-0007Sj-30 for 60527@debbugs.gnu.org; Wed, 04 Jan 2023 14:11:45 -0500 Original-Received: by mail-pf1-f172.google.com with SMTP id e21so13973053pfl.1 for <60527@debbugs.gnu.org>; Wed, 04 Jan 2023 11:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=AXuu/RNedAkKxcl6s3MSGmrhwqYOw7EN6Qsz+u16XmM=; b=J/b8t0721DAttxwEMnZhs8adpmeCCXjXLYntN7hirA1M4IVKmegiJFnI3/KyS4zcHo YkYrP0DNICOxsA2tAsSZe+lIIsXvO5tq8CHnjjPLj9uksTIkaUzBi6Btl3DJvcqgEXRX oy06z0U/OZbp7R4eCH4ttc1dQldVHZqbZwSsT6o9OW/W0fLaIGHk2qLsd1Bhf8ISeom7 XYbT/Y5JoTPiNuPdP+4TM8Ixdy0ES+dWn+kBZAxbG90XjMODP8IMPE2zkCRB/+U0dS5a mxD5Y9CQXUsZPt9vo95T96s7uD1q9e3DNcLKec6ykMm5zYkNdqe2QK9a6IAAZuzVw1qt OVOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AXuu/RNedAkKxcl6s3MSGmrhwqYOw7EN6Qsz+u16XmM=; b=cG/9fLbenpKO/FvfNh4j3hkE8KY0+bcU5tGRNZrjIi2M9jEWz1Vsmksp5DTcYobZUI 019B8Rnil9lkyUYtFB/vwZXIlaGzaxFGCXxyDPbgEoadVdtnxXUhR1OwAdqLYKHYL1PY f+/+TTM/YRNS3/vIgosYvbA8wff9XqyORvCd9/eNZAyAR7X2StkaiBfEJIyvVB96zFjt KvZ70BXVUbVdnqc9nseqzJNvXqWb3W4E8/GaCWknBGPS84tWBXsP0p9GX9+icqlMbdQp mQpwhlESmF4w9NeGu9YHNcby//Hi9n9aV1VAcPaRltQhYsfoqtBT34UIsqSDoDWXRK+v f67Q== X-Gm-Message-State: AFqh2kokYWfsazR4jTKzEWFX3vOvQ5g5ZhscWFDrVTmQWHNrMPiFLOAy sgz9xRe64bEj1iJaJBPreGQ= X-Google-Smtp-Source: AMrXdXsOSwysVISgPYVeIMZY/zaV3GGHXqGDlUXSnq3JWGqG0+iqlc8iNflaf3Z9N24lum8bVeYQ1A== X-Received: by 2002:a05:6a00:1245:b0:581:ad35:406f with SMTP id u5-20020a056a00124500b00581ad35406fmr24046230pfi.21.1672859499177; Wed, 04 Jan 2023 11:11:39 -0800 (PST) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id a3-20020a624d03000000b0056ee49d6e95sm22677607pfb.86.2023.01.04.11.11.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 11:11:38 -0800 (PST) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252531 Archived-At: On 1/3/2023 11:05 AM, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > I wish the SPC binding to `minibuffer-complete-word` would go because it > makes it hard to type SPC in the minibuffer whenever there's completion. [snip] > So my favorite option is indeed to simply remove this binding. > Those few users who like it and use it (probably long-time users of > Emacs) could easily get it back with: > > (define-key minibuffer-local-completion-map > " " 'minibuffer-complete-word) This would be my preference too, so long as there were an easy way for people who like the old behavior to get it back. (Would it be sufficient to just put that snippet in a NEWS entry?) > Another option is to change `minibuffer-complete-word` so that instead > of beeping "No match", it inserts a SPC when there's no completion and > `require-match` is nil (after checking that the command was invoked via > SPC). I'm not sure about this one; if it were hard to predict ahead of time what SPC will do, then it could be even less usable. For example, if I want to insert a literal space, I might press SPC only to find that it performs completion. So then I have to undo and press "C-q SPC" to get what I want. > Yet another option would be to let callers of `completing-read` indicate > that it's likely the users will sometimes want to type a SPC character > for this specific minibuffer input (i.e. `completing-read` would then > use a map like `minibuffer-local-filename-completion-map`). If this would work, it seems like a good compromise. But do the callers know for sure how this should be set? If they got it wrong, then it might have the effect of annoying both users who like the current binding and those who don't. (Similar to the above, there's not much worse than a button that *sometimes* does what you want.) As yet another option, how about doing something like the first one, but gate it behind a defcustom? That provides an easy way for users to get the behavior they want, without having to deal with figuring out minibuffer bindings. (If we had a time machine, the defcustom probably wouldn't be necessary, but I think it makes sense to provide an easy escape hatch if changing some long-standing feature.)