* bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map @ 2014-01-23 13:06 Roland Winkler 2014-01-23 18:03 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Roland Winkler @ 2014-01-23 13:06 UTC (permalink / raw) To: 16528 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 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 2021-08-20 15:00 ` Lars Ingebrigtsen 0 siblings, 2 replies; 8+ messages in thread From: Stefan Monnier @ 2014-01-23 18:03 UTC (permalink / raw) To: Roland Winkler; +Cc: 16528 > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 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 1 sibling, 1 reply; 8+ messages in thread From: Roland Winkler @ 2014-01-23 19:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: 16528 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 2014-01-23 19:02 ` Roland Winkler @ 2014-01-23 19:16 ` Drew Adams 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams @ 2014-01-23 19:16 UTC (permalink / raw) To: Roland Winkler, Stefan Monnier; +Cc: 16528 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 2014-01-23 18:03 ` Stefan Monnier 2014-01-23 19:02 ` Roland Winkler @ 2021-08-20 15:00 ` Lars Ingebrigtsen 2021-08-20 16:38 ` bug#16528: [External] : " Drew Adams 1 sibling, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2021-08-20 15:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: 16528, Roland Winkler 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 2021-08-20 15:00 ` Lars Ingebrigtsen @ 2021-08-20 16:38 ` Drew Adams 2021-08-20 19:51 ` Kévin Le Gouguec 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2021-08-20 16:38 UTC (permalink / raw) To: Lars Ingebrigtsen, Stefan Monnier; +Cc: 16528@debbugs.gnu.org, 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. > > > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 2021-08-20 16:38 ` bug#16528: [External] : " Drew Adams @ 2021-08-20 19:51 ` Kévin Le Gouguec 2021-08-20 21:11 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Kévin Le Gouguec @ 2021-08-20 19:51 UTC (permalink / raw) To: Drew Adams Cc: Lars Ingebrigtsen, 16528@debbugs.gnu.org, Stefan Monnier, Roland Winkler 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#16528: [External] : bug#16528: 24.3; too many keybindings in minibuffer-local-completion-map 2021-08-20 19:51 ` Kévin Le Gouguec @ 2021-08-20 21:11 ` Drew Adams 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams @ 2021-08-20 21:11 UTC (permalink / raw) To: Kévin Le Gouguec Cc: Lars Ingebrigtsen, 16528@debbugs.gnu.org, Stefan Monnier, Roland Winkler > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-08-20 21:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 ` bug#16528: [External] : " Drew Adams 2021-08-20 19:51 ` Kévin Le Gouguec 2021-08-20 21:11 ` Drew Adams
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).