bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Roland Winkler]

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.


In GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2013-10-04 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.4 LTS

bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Stefan Monnier]

> 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.

I can see a few different directions we could go to try and solve those
problems:
- change the default completion map so SPC is not bound any more.
- provide some way to call completing-read, specifying that this
  particular completion should, just like file-name completion, not bind
  SPC to minibuffer-complete-word.
- change the behavior of minibuffer-complete-word to be more DWIMish.
  For example, if completion can't be performed (no valid candidates, or
  no shared prefix among the candidates), instead of beeping, it could
  insert a SPC.

I haven't thought much about ? because that one has not been nearly as
annoying.  The problem is largely similar, except that the harms are all
much less severe (both of the current situation and of the possible
fixes).
  

        Stefan

bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Roland Winkler]

On Thu Jan 23 2014 Stefan Monnier wrote:
> 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.

So it seems to me there are two views on this:

- there might be situations where the user wants to customize the
  keybindings provided by minibuffer-local-completion-map
  (this customization would then probably affect all calls of
  completing-read)

- in other cases, the code calling completing-read might want to
  provide some non-default keybindings (which would then affect only
  certain calls of completing-read, but it would apply to all users)

I do not know how common each of these cases might be.  (I never use
SPC for completion, but that's just me.)

Roland

bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Drew Adams]

FWIW, in Icicles:

1. All of these keys are self-inserting: SPC, ?, C-j.
2. A separate key is used to word-complete: M-SPC, not TAB.

IOW, for word completion, just use a different key.

(I would request that you do not use any combination of keys or
modifiers with TAB or <backtab> for word completion, however.)

My feeling is that word completion is generally not very important,
but I provide a key for it.

To me, SPC is far more useful if it is self-inserting, not bound
to some completion command.  But then Icicles uses completion for
lots of things, including lots of kinds of candidates that have
embedded SPC chars.

I feel the same about ? and C-j (newline).  There is no good reason
for these not to be self-inserting, IMO.  Again, in Icicles there
are lots of kinds of completion candidates, including multi-line
ones and ones that have embedded ? chars.

HTH.

bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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), 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?

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Drew Adams]

> >> 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

bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Kévin Le Gouguec]

Drew Adams <drew.adams@oracle.com> writes:

>> 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?

I don't know about good arguments, but FWIW on AZERTY, where '-' is a
pain to reach for, I enjoy 'SPC' doing word completion and inserting
hyphens for Elisp symbols on M-x, C-h v, C-h f, etc.

I'll admit it's a pretty niche use-case, although off the top of my
head, I can't find much uses for self-inserting SPC/?/C-j in the
minibuffer either (Emacs 28's yank-from-kill-ring comes to mind, but '?'
and 'SPC' are already self-inserting there[1]).


[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/simple.el?id=00a9c50ad7c82f72b422100624f7f125d717c00f#n5793

bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map

[Drew Adams]

> I don't know about good arguments, but FWIW on AZERTY, where '-' is a
> pain to reach for, I enjoy 'SPC' doing word completion and inserting
> hyphens for Elisp symbols on M-x, C-h v, C-h f, etc.

FWIW, Icicles has (always has had) an option for which
keys to use for word-completion.  The default value is
`M-SPC'.

`icicle-word-completion-keys':

  ...because the spacebar is such a convenient key to
  hit, other people prefer to use `SPC' for word
  completion, and to insert a space some other way.
  The usual way to do that is via `C-q SPC', but command
  `icicle-insert-a-space' is provided for convenience.
  You can bind this to `M-SPC', for instance, in
  `minibuffer-local-completion-map',
  `minibuffer-local-completion-map', and
  `minibuffer-local-must-match-map'.

And if Emacs thought that word-completion for AZERTY
keyboards (or anything else) would likely result in
a significant number of users wanting to customize the
key(s) to use for it, Emacs too could offer an option.

Or else users such as yourself would just add a
binding for SPC in the relevant minibuffer keymaps. 

> I'll admit it's a pretty niche use-case, although off the top of my
> head, I can't find much uses for self-inserting SPC/?/C-j in the
> minibuffer either

Hearing that, I'm guessing your use of minibuffer
completion doesn't encounter a lot of different kinds
of completion candidates.  That's fine; users are
different, as are the things they complete.

> (Emacs 28's yank-from-kill-ring comes to mind, but
> '?' and 'SPC' are already self-inserting there[1]).

Individual commands can bind whatever keys in whatever
minibuffer keymaps make most sense for those commands.

But I think the general case, that is, no a priori
knowledge of what kinds of completion candidates might
be used, should treat those 3 keys as self-inserting.

Instead of the commands you mentioned making SPC
self-inserting, commands for which SPC should have
some action _other than_ self-insertion should bind
SPC to that particular action.  That's applying
particular use-case knowledge to completion for that
use case.

The normal and generally expected action for SPC is
self-insertion.  That makes sense for the minibuffer
also, in general.  Any text at all can be a completion
candidate.  And a minibuffer is pretty much a general
editing buffer.