unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "16528@debbugs.gnu.org" <16528@debbugs.gnu.org>,
	Roland Winkler <winkler@gnu.org>
Subject: bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map
Date: Fri, 20 Aug 2021 16:38:35 +0000	[thread overview]
Message-ID: <SJ0PR10MB54883B74CFF3B6FE823EC0AEF3C19@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87sfz45ffg.fsf@gnus.org>

> >> minibuffer-local-completion-map binds SPC to minibuffer-complete-word
> >> and ? to minibuffer-completion-help.  It should be possible without
> >> too much hackery to run completing-read in a less obtrusive mode
> >> where these keys simply insert the respective characters.
> >
> > Indeed, this binding can be annoying.  Some people use it heavily (and
> > rarely use TAB, IIUC), tho, so removing it is a bit tricky, but it was
> > annoying enough for files that file-name completion now uses a special
> > map where SPC is not bound to minibuffer-complete-word any more.
> 
> Indeed -- I have
> 
> (define-key minibuffer-local-completion-map " " 'self-insert-command)
> (define-key minibuffer-local-completion-map "?" 'self-insert-command)
> 
> in my ~/.emacs.
> 
> But I don't think we can change the defaults here (it would drive (some)
> people crazy),

Who?  Why?  How consequential?  What about others?

How about one good argument why `?', `SPC', and `C-j'
shouldn't be self-inserting in the minibuffer, in
general?  If you were designing Emacs today, would
you make the same argument?

> so we'd be talking about adding a user option.  But I can
> totally see some people wanting to only make space be self-inserting, or
> just the question mark, and in that case, just doing the `define-key'
> things is better for users, I think?

That's why we have the minibuffer keymaps, as you
showed above.  Again, what does "some people" mean
- just whom do you see bothered by such a change
in default bindings?

"doing the `define-key' things" should be necessary
for only a minority of users.  The default behavior
should be what's most sensible in general, and it
should be based on what minibuffer completion might
do in general.

Any particular command can bind minibuffer keys as
appropriate - nothing prevents some command from
giving SPC, `?', or `C-j' a particular behavior.
But in general? Default bindings for these?  They
should be self-inserting, other things being equal.

Minibuffer completion is "nowadays" as general as
can be.  Completion candidates that contain SPC
chars, newline chars, and question marks are no
longer rare.

When I started trying to make more use of completion
back in 2005, minibuffer completion was pretty much
limited to file names, commands (`M-x'), and buffer
names.  And yes, such chars were relatively uncommon
in completion candidates (though SPC was common in
MS Windows file names).

It took a long time, but we finally got `SPC' to be
self-inserting for file-name completion.  It's high
time for Emacs to catch up with the many uses of
completion today.

This is not your grandmother's minibuffer anymore.

> So I've just added that to the user manual, and I'm closing this bug
> report.

Too bad.

___

There are no doubt tickets and emacs-devel discussions
about this older than these (i.e., before 2005), but I
didn't find them in a quick search.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9972#34

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11182#25

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16528#14

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25441#21

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36745#8

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36745#23

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44611#27

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47150

---

https://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00577.html

https://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01045.html

https://lists.gnu.org/archive/html/emacs-devel/2014-04/msg00246.html

https://lists.gnu.org/archive/html/emacs-devel/2014-11/msg01521.html

https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00250.html

https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00668.html

https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00848.html





  reply	other threads:[~2021-08-20 16:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 13:06 bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map Roland Winkler
2014-01-23 18:03 ` Stefan Monnier
2014-01-23 19:02   ` Roland Winkler
2014-01-23 19:16     ` Drew Adams
2021-08-20 15:00   ` Lars Ingebrigtsen
2021-08-20 16:38     ` Drew Adams [this message]
2021-08-20 19:51       ` bug#16528: [External] : " Kévin Le Gouguec
2021-08-20 21:11         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB54883B74CFF3B6FE823EC0AEF3C19@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=16528@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=winkler@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).