bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuf


From: Drew Adams
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

> >> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]