* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode @ 2013-01-31 19:41 Drew Adams 2013-02-04 10:27 ` Jambunathan K ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Drew Adams @ 2013-01-31 19:41 UTC (permalink / raw) To: 13602 Icomplete mode is general, for use with all minibuffers, whatever the kind of input being done (kind of completion or input without completion, etc.). It needs to be sensitive to this and not impose itself like a brute. There are many minibuffer keymaps, with many keys in them. And applications often define more keys in these maps. These Icomplete keybindings are inappropriate: (defvar icomplete-minibuffer-map (let ((map (make-sparse-keymap))) (define-key map [?\M-\t] 'minibuffer-force-complete) (define-key map [?\C-j] 'minibuffer-force-complete-and-exit) (define-key map [?\C-s] 'icomplete-forward-completions) (define-key map [?\C-r] 'icomplete-backward-completions) map)) It is not kosher to bind such keys in the minibuffer in a general mode. Let users bind them if they like. In particular: C-s and C-r are used to search minibuffer text (e.g. move the cursor). M-TAB is useful in the minibuffer to complete names. And users and applications can reasonably bind C-j to be self-inserting in the minibuffer, just as some do for SPC. `icomplete-mode-map' should not even be unconditionally imposed as part of the local map when Icomplete mode is turned on. You have made it difficult for users to get the normal, traditional Icomplete behavior without your recent additions for cycling. Misguided. Please let users more easily choose whether they want that. I propose that you create a separate mode for using `icomplete-mode-map', analogous to the separation between `cua-mode' and `cua-selection-mode'. That is clean and simple for you to do. Users turning on Icomplete mode would not get these key bindings. Users turning on the new Icomplet-With-Cycling mode (or whatever name you like) would get the current behavior you have defined: Icomplete plus your keybindings. This approach would give users more contol - an easy way to get your new cycling feature or to do without it. If they choose to use it, they can always change the key bindings. Even in that case, my suggestion would be that you pick different default bindings. But at least with this approach no bindings would not be imposed on regular Icomplete users. (defun cua-selection-mode (arg) "Enable CUA selection mode without the C-z/C-x/C-c/C-v bindings." (interactive "P") (setq-default cua-enable-cua-keys nil) ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (if (not (called-interactively-p 'any)) (cua-mode arg) ;; Use call-interactive to turn a nil prefix arg into `toggle'. (call-interactively 'cua-mode) (customize-mark-as-set 'cua-enable-cua-keys))) In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2013-01-25 on ODIEONE Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib' ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-01-31 19:41 bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Drew Adams @ 2013-02-04 10:27 ` Jambunathan K 2013-02-04 16:02 ` Drew Adams 2013-02-04 11:20 ` Dmitry Gutov 2013-02-04 14:51 ` Stefan Monnier 2 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-04 10:27 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 > These Icomplete keybindings are inappropriate: > > (defvar icomplete-minibuffer-map > (let ((map (make-sparse-keymap))) > (define-key map [?\M-\t] 'minibuffer-force-complete) > (define-key map [?\C-j] 'minibuffer-force-complete-and-exit) > (define-key map [?\C-s] 'icomplete-forward-completions) > (define-key map [?\C-r] 'icomplete-backward-completions) > map)) > > It is not kosher to bind such keys in the minibuffer in a general mode. > Let users bind them if they like. > In particular: C-s and C-r are used to search minibuffer text (e.g. move > the cursor). M-TAB is useful in the minibuffer to complete names. And > users and applications can reasonably bind C-j to be self-inserting in > the minibuffer, just as some do for SPC. You don't use ido-mode, do you? These bindings mimic the behaviour of ido-mode. As a user, I can't be too concerned with the backend library facilitating completions. > `icomplete-mode-map' should not even be unconditionally imposed as part > of the local map when Icomplete mode is turned on. I don't see any `icomplete-mode-map'. Does playing around with `icomplete-minibuffer-setup-hook' help with getting the behaviour you want? In `icomplete-minibuffer-setup', should setting up of composed map be delayed until after the `icomplete-minibuffer-setup' had a chance to run? I am posing this as a question, for you have better understanding of keymaps than I do. > You have made it difficult for users to get the normal, traditional > Icomplete behavior without your recent additions for cycling. > Misguided. Please let users more easily choose whether they want that. May be we should wait until one another user complains about hijacking of search keys to useless ends. > I propose that you create a separate mode for using > `icomplete-mode-map', analogous to the separation between `cua-mode' and > `cua-selection-mode'. That is clean and simple for you to do. > > Users turning on Icomplete mode would not get these key bindings. Users > turning on the new Icomplet-With-Cycling mode (or whatever name you > like) would get the current behavior you have defined: Icomplete plus > your keybindings. > > This approach would give users more contol - an easy way to get your new > cycling feature or to do without it. If they choose to use it, they can > always change the key bindings. Even in that case, my suggestion would > be that you pick different default bindings. But at least with this > approach no bindings would not be imposed on regular Icomplete users. > > (defun cua-selection-mode (arg) > "Enable CUA selection mode without the C-z/C-x/C-c/C-v bindings." > (interactive "P") > (setq-default cua-enable-cua-keys nil) > ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > (if (not (called-interactively-p 'any)) > (cua-mode arg) > ;; Use call-interactive to turn a nil prefix arg into `toggle'. > (call-interactively 'cua-mode) > (customize-mark-as-set 'cua-enable-cua-keys))) > > In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) > of 2013-01-25 on ODIEONE > Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp > Windowing system distributor `Microsoft Corp.', version 5.1.2600 > Configured using: > `configure --with-gcc (4.7) --no-opt --enable-checking --cflags > -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib' -- ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 10:27 ` Jambunathan K @ 2013-02-04 16:02 ` Drew Adams 2013-02-04 16:36 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-04 16:02 UTC (permalink / raw) To: 'Jambunathan K'; +Cc: 13602 > You don't use ido-mode, do you? No, thank you. And it is not the default behavior for Emacs either. You won't even find it described in the Emacs manual, where the minibuffer is described in detail. The real question is "Have you used Emacs (and Icomplete) without Ido mode?" That's the use case I'm concerned about. If you wear Ido-colored glasses when thinking about this then you will likely not see clearly that a user can want these keys to be left alone, to be used otherwise, as before. > These bindings mimic the behaviour of ido-mode. Yes, I know. (Actually, it is Ido that mimicked Icomplete and IswitchB.) If you want Ido then you do not really need Icomplete anyway. Regardless, these keys should be optional for Icomplete. Icomplete is not Ido. > As a user, I can't be too concerned with the > backend library facilitating completions. In changing Icomplete for all users you are acting as an Emacs developer, not just as one user. And the concern for users is not dependent on any backend libraries. `emacs -Q' does not put you in Ido mode, and it lets you use all kinds of keys in the minibuffer, including C-s and C-r. Icomplete should continue to be compatible with this, if a user so prefers. Users can prefer not to have Icomplete bind such keys, to keep Icomplete for what it was originally designed (informative help), and to allow those keys to be used otherwise in the minibuffer, just as before. The minibuffer is a buffer where you can _edit_ your input. That Ido restricts the minibuffer behavior, removing this editing possibility (well, restricting it modally), is a specialty of Ido - it is not the normal behavior of the Emacs minibuffer. The minibuffer is much bigger in behavior and possibilities than what Ido allows for. Nothing wrong with Ido doing what it does to the minibuffer, for its own purposes. But that's not the Emacs minibuffer, in general. And Icomplete has always been compatible with the general, emacs -Q, minibuffer. This should continue, at least as the default behavior. These key bindings should be optional, in a separate mode, just as for CUA mode and CUA Selection mode. Let me be clear. I have nothing against Ido or against the keys you defined for use with Icomplete. I believe that both can be useful, and I applaud your addition of the keys to Icomplete. The point is that they should be optional. Turning on Icomplete mode should not suddenly remove the possibility of using these or any other keys in the minibuffer for their normal behavior. > Does playing around with `icomplete-minibuffer-setup-hook' > help with getting the behaviour you want? Users should not need to so play around. > In `icomplete-minibuffer-setup', should setting up of composed map be > delayed until after the `icomplete-minibuffer-setup' had a chance to > run? I am posing this as a question, for you have better > understanding of keymaps than I do. I seriously doubt that I have a better understanding of keymaps than you do. What should be done is to put the binding of such keys into a separate, optional mode. Keep Icomplete mode for what it was intended (information display), and add a mode on top of it that additionally provides the Ido-like keys. Simple, friendly to users, no change of the minibuffer keys unless you want it. Here is what I do, in case it helps. (The only reason for the mode var defvar and the eval here is so the code will work also with older Emacs versions. If integrated with icomplete.el such code could be greatly simplified.) (defvar icompletep-ORIG-icomplete-minibuffer-map) (defvar icompletep-cycling-mode nil) (when (boundp 'icomplete-minibuffer-map) ; Emacs 24.4+ (setq icompletep-ORIG-icomplete-minibuffer-map icomplete-minibuffer-map ; Save it and wipe it out. icomplete-minibuffer-map nil) (eval '(define-minor-mode icompletep-cycling-mode "Icomplete, with cycling keys enabled if on, disabled if off. If off then the cycling keys of Icomplete mode are free for their normal minibuffer uses. The default Icomplete-mode cycling keys are: M-TAB\t- complete to exact match, repeat to cycle C-j\t- complete to first match and exit minibuffer C-s\t- cycle first entry to end C-r\t- cycle last entry to start If you want Icomplete cycling behavior but do not want to use these keys for it, customize the bindings in `icomplete-minibuffer-map'. Turning this mode on also turns on Icomplete mode. Turning it off does not turn Icomplete mode on or off." nil nil nil (when icompletep-cycling-mode (icomplete-mode 99)) (setq icomplete-minibuffer-map (and icompletep-cycling-mode icompletep-ORIG-icomplete-minibuffer-map)))) (icompletep-cycling-mode -99)) A user wanting the behavior you want need only turn on `icompletep-cycling-mode' instead of `icomplete-mode'. What's more, a user can bind the mode to a key, to easily toggle the cycling keys on/off, without leaving Icomplete mode. > > You have made it difficult for users to get the normal, traditional > > Icomplete behavior without your recent additions for cycling. > > Misguided. Please let users more easily choose whether > > they want that. > > May be we should wait until one another user complains about hijacking > of search keys to useless ends. Why? Why not return Icomplete to what it was and give Ido-oriented users an easy choice to get the behavior you like? It is simple to do that. And I never said that you were "hijacking" these keys to "useless ends". The ends you propose are useful. But they should be optional, as these keys can also be useful with their usual (or with other) bindings. I am in favor of the addition of the possibility of cycling to Icomplete mode. But it should be optional; that's all. The model of CUA mode and CUA selection modes should serve here: Use another mode if you want the cycling keys in addition to the information behavior of Icomplete. Key "hijacking" off by default, for Icomplete mode. > > (setq-default cua-enable-cua-keys nil) > > ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 16:02 ` Drew Adams @ 2013-02-04 16:36 ` Jambunathan K 2013-02-04 17:34 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-04 16:36 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 >> These bindings mimic the behaviour of ido-mode. > > Yes, I know. (Actually, it is Ido that mimicked Icomplete and IswitchB.) > > If you want Ido then you do not really need Icomplete anyway. Are you saying: "ido can do what Icomplete does *without* the user modifying any of the completing-read calls in existing libraries?". I remember modifying `completing-read-function' at some point in time. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 16:36 ` Jambunathan K @ 2013-02-04 17:34 ` Drew Adams 0 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-04 17:34 UTC (permalink / raw) To: 'Jambunathan K'; +Cc: 13602 > >> These bindings mimic the behaviour of ido-mode. > > > > Yes, I know. (Actually, it is Ido that mimicked Icomplete > > and IswitchB.) > > > > If you want Ido then you do not really need Icomplete anyway. > > Are you saying: "ido can do what Icomplete does *without* the user > modifying any of the completing-read calls in existing libraries?". > > I remember modifying `completing-read-function' at some point in time. Sorry, I don't know. My impression was that Ido offers what is offered by Icomplete + the new keys. Whether it offers that out of the box is another question. * If not, and if you want it to do that out of the box, then it is Ido mode that should be modified. * If not, and if you want that to be optional but not turned on by default, then that too should be done for Ido mode itself, as opposed to being done for Icomplete mode. Again, I am not at all opposed to adding these keys to Icomplete mode as an optional, Ido-like behavior. I am in favor it. The key word, however, is "optional". I would prefer that (a) the default behavior not change any minibuffer keybindings and (b) that users can choose to toggle the key bindings on/off easily, as a separate mode. This is simple to implement and simple and clear for users to make use of. And no, by "optional" I do not mean that it is enough to tell users to go take a hike and fiddle with Lisp code (e.g. key bindings), to restore the passive, informative-only Icomplete that they've known and loved for decades, and that has always cohabited well with pretty-much any Emacs minibuffer behavior. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-01-31 19:41 bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Drew Adams 2013-02-04 10:27 ` Jambunathan K @ 2013-02-04 11:20 ` Dmitry Gutov 2013-02-04 16:16 ` Drew Adams 2013-02-04 14:51 ` Stefan Monnier 2 siblings, 1 reply; 42+ messages in thread From: Dmitry Gutov @ 2013-02-04 11:20 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 "Drew Adams" <drew.adams@oracle.com> writes: > Icomplete mode is general, for use with all minibuffers, whatever the > kind of input being done (kind of completion or input without > completion, etc.). No, it's not, it's only used in specific cases. For example, icomplete is not used in minibuffer during eval-expression. > It needs to be sensitive to this and not impose > itself like a brute. There are many minibuffer keymaps, with many keys > in them. And applications often define more keys in these maps. > > These Icomplete keybindings are inappropriate: > > (defvar icomplete-minibuffer-map > (let ((map (make-sparse-keymap))) > (define-key map [?\M-\t] 'minibuffer-force-complete) > (define-key map [?\C-j] 'minibuffer-force-complete-and-exit) > (define-key map [?\C-s] 'icomplete-forward-completions) > (define-key map [?\C-r] 'icomplete-backward-completions) > map)) > > It is not kosher to bind such keys in the minibuffer in a general mode. > Let users bind them if they like. I'd like to comment on this as a ido-mode user. > In particular: C-s and C-r are used to search minibuffer text (e.g. > move Instead of searching though the already entered text, this behavior allows you to "search" through the candidates. Since this mode is usually enabled when you're trying to write or pick a single symbol, not a bunch of text, this strikes me as more appropriate. > the cursor). M-TAB is useful in the minibuffer to complete names. Likewise, minibuffer-force-complete does complete the current symbol. What's the problematic use case? --Dmitry ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 11:20 ` Dmitry Gutov @ 2013-02-04 16:16 ` Drew Adams 2013-02-04 22:04 ` Dmitry Gutov 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-04 16:16 UTC (permalink / raw) To: 'Dmitry Gutov'; +Cc: 13602 > > Icomplete mode is general, for use with all minibuffers, > > whatever the kind of input being done (kind of completion > > or input without completion, etc.). > > No, it's not, it's only used in specific cases. > For example, icomplete is not used in minibuffer during > eval-expression. Nitpicking. Completion. That should have been understood from the context: "I _complete_" mode. Icompletion is about completion contexts. > > Let users bind them if they like. > > I'd like to comment on this as a ido-mode user. Great. But please recognize that not all Emacs users use Ido. And it is not even the default minibuffer behavior for Emacs. And it is not even described in the Emacs manual. IOW, your parochial point of view is of course welcome and relevant, but please don't mistake it for how users in general view using the minibuffer. > > In particular: C-s and C-r are used to search minibuffer > > text (e.g. move > > Instead of searching though the already entered text, ("Already entered" does not necessarily mean typed, BTW.) > this behavior allows you to "search" through the candidates. Yes, I know. So what? The point is that this substitutes the original, normal, usual behavior of those keys with another behavior. A given user can prefer either behavior: normal or new. Let users choose easily. That's the point. There are lots of Emacs users who have been using Icomplete for years (yes, even before Ido existed), and appreciate its informative help. You should not just assume, because you are an Ido enthusiast, that all users now want to switch to an Ido-like behavior for keys they have been able to use otherwise. > this strikes me as more appropriate. So in your case you would opt in to use the keys. What's the problem? (Though as an Ido user you really do not need Icomplete at all, do you?) You should get your way, for your own use. Another user should be able to get the longstanding Icomplete behavior, for her own use. It should be easy for each to get the behavior preferred, and even to switch to the other behavior. This is trivial to implement. What so much resistance to giving users the choice? Why so much insistence on bending Icomplete to be Ido-like for all? Users are free to use Ido if they like. Where's the beef? ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 16:16 ` Drew Adams @ 2013-02-04 22:04 ` Dmitry Gutov 2013-02-04 23:33 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Dmitry Gutov @ 2013-02-04 22:04 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 On 04.02.2013 20:16, Drew Adams wrote: >>> Icomplete mode is general, for use with all minibuffers, >>> whatever the kind of input being done (kind of completion >>> or input without completion, etc.). >> >> No, it's not, it's only used in specific cases. >> For example, icomplete is not used in minibuffer during >> eval-expression. > > Nitpicking. Completion. That should have been understood from the context: "I > _complete_" mode. Icompletion is about completion contexts. It's in the name, but not in your statement above. As such, your statement was false. You also mentioned "input without completion", whatever that is. My point is, as long as ido and icomplete are used in completion situations, and they're used to complete relatively short things, they obviate the need for all three commands you're complaining about. Searching back and forward though a short input string is quite useless, and `minibuffer-complete' essentially conflicts with the main function of ido and icomplete: show the available candidates inline. >>> Let users bind them if they like. >> >> I'd like to comment on this as a ido-mode user. > > Great. But please recognize that not all Emacs users use Ido. And it is not > even the default minibuffer behavior for Emacs. And it is not even described in > the Emacs manual. Is icomplete described in the Emacs manual? > IOW, your parochial point of view is of course welcome and relevant, but please > don't mistake it for how users in general view using the minibuffer. I'm well-aware how Emacs looks and works by default, thank you very much. It also has a rich ecosystems with packages modifying its behavior every which way, according to user needs and whims. >>> In particular: C-s and C-r are used to search minibuffer >>> text (e.g. move >> >> Instead of searching though the already entered text, > > ("Already entered" does not necessarily mean typed, BTW.) Yes. Slightly less useless in this case, but this is a rare one, naturally. >> this behavior allows you to "search" through the candidates. > > Yes, I know. So what? The point is that this substitutes the original, normal, > usual behavior of those keys with another behavior. icomplete is off by default, so no user is forced to use the non-default behavior. > You should not just assume, because you are an Ido enthusiast, that all users > now want to switch to an Ido-like behavior for keys they have been able to use > otherwise. Do I come across as a five-year-old or something? >> this strikes me as more appropriate. > > So in your case you would opt in to use the keys. What's the problem? (Though > as an Ido user you really do not need Icomplete at all, do you?) I don't. But you can make most of the same arguments in the context of ido-mode, can't you? > You should get your way, for your own use. Another user should be able to get > the longstanding Icomplete behavior, for her own use. ...maybe except this one. How long ago has this "longstanding" behavior changed? > It should be easy for each to get the behavior preferred, and even to switch to > the other behavior. > > This is trivial to implement. What so much resistance to giving users the > choice? Why so much insistence on bending Icomplete to be Ido-like for all? > Users are free to use Ido if they like. Where's the beef? I believe most of the resistance is against your suggestion that the minor mode with modified keybindings should be off by default. If you hide nice things from users, some portion of users with never find them. So, it hurts discoverability. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 22:04 ` Dmitry Gutov @ 2013-02-04 23:33 ` Drew Adams 0 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-04 23:33 UTC (permalink / raw) To: 'Dmitry Gutov'; +Cc: 13602 > My point is, as long as ido and icomplete are used in completion > situations, If you assume that Ido is used, then why use Icomplete too? > and they're used to complete relatively short things, Unwarranted assumption. (Of course, it depends on your "relatively".) And even when minibuffer content is relatively short, Isearch can be a quick way to move around: think cursor movement, not search. If you use Ido then you are perhaps not so used to editing and moving around the minibuffer text. But for those not using Ido, editing and moving around, including with isearch, are not uncommon. > they obviate the need for all three commands you're complaining about. No, they don't. And my complaint is not only about any particular three keys you might choose to co-opt by default. My beef is with co-opting any keys by default. Icomplete has a long, distinguished career helping Emacs users by passively showing the available completions and not interfering with any minibuffer key bindings (N.B. _any_). It should continue to offer that service that it does so well. If you want to add an optional mode that offers other, Ido-like things, fine. Just make it optional, please. > Searching back and forward though a short input string is > quite useless, See above. Searching to move around the minibuffer might be useless in Ido. But not everyone prefers to use Ido. But again, it's not about the particular keys. It's about stealing keys from their usual use in the Emacs minibuffer. Not the Ido minibuffer, which is quite special and atypical, but the Emacs minibuffer, in general. > >> I'd like to comment on this as a ido-mode user. > > > > Great. But please recognize that not all Emacs users use > > Ido. And it is not even the default minibuffer behavior for > > Emacs. And it is not even described in the Emacs manual. > > Is icomplete described in the Emacs manual? You're missing the point. _Emacs_ is described in the Emacs manual. This is about the Emacs minibuffer. Including the behavior you get from `emacs -Q'. That minibuffer behavior is described in the manual, yes. Icomplete has until now not interfered with that behavior, in particular with whatever keys are available in the minibuffer, in whatever mode, from whatever library, AFAIK. Icomplete has always played well with whatever minibuffer bindings you might use or prefer. It has only provided passive help: info about available completions. > I'm well-aware how Emacs looks and works by default, thank you very > much. It also has a rich ecosystems with packages modifying > its behavior every which way, according to user needs and whims. Good. And until now, Icomplete has played well with all of those users and their individual whims. It has not imposed key bindings. It should remain so well behaved and continue to be useful whatever bindings might be in effect, from emacs -Q or from other libraries. It gets along with so many modes in large part because it is keyless: it just provides info. Nearly every mode can take advantage of it, regardless of how that mode might define minibuffer behavior. It is indeed about the many Emacs users and their whims, and not just the whims of a developer or two. Let users easily get your preferred behavior, sure, but let them just as easily toggle that off and return to the bindings provided by emacs -Q or other packages they might choose. Why do you need to go all the way and impose your preferred behavior by default, and leave fiddling with keymaps as the only way to restore the bindings that would otherwise have remained current? > >> this behavior allows you to "search" through the candidates. > > > > Yes, I know. So what? The point is that this substitutes > > the original, normal, usual behavior of those keys with another > > behavior. > > icomplete is off by default, so no user is forced to use the > non-default behavior. The discussion is about Icomplete behavior. The default behavior of Icomplete. You are veering off the road. > > You should not just assume, because you are an Ido enthusiast, > > that all users now want to switch to an Ido-like behavior for > > keys they have been able to use otherwise. > > Do I come across as a five-year-old or something? I'll have to let that one pass. > >> this strikes me as more appropriate. > > > > So in your case you would opt in to use the keys. What's > > the problem? (Though as an Ido user you really do not need > > Icomplete at all, do you?) > > I don't. But you can make most of the same arguments in the > context of ido-mode, can't you? If you do not need Icomplete then why do you need it to interact like Ido? I do use Icomplete. And I want it to play well, for me and others, with emacs -Q and with other libraries that bind minibuffer keys. And no, I certainly would not make ANY of the same arguments wrt Ido that I've made about Icomplete. Icomplete is a long established mode that provides completion information. That simple help function serves a useful purpose. Until now Icomplete has not done anything else. Ido has from the beginning involved exceptional user interaction to choose candidates. It has never been something that you could use with the normal (e.g. emacs -Q) minibuffer interaction or with other-library minibuffer interactions. Ido radically alters minibuffer interaction - it plays by its own rules. It has provided its own, alternative minibuffer UI from the beginning. That is its raison d'etre. Nothing wrong with that; it is what Ido is intended to do. Totally different from Icomplete. You have not heard me make any suggestion about changing Ido behavior. > > You should get your way, for your own use. Another user > > should be able to get the longstanding Icomplete behavior, > > for her own use. > > ...maybe except this one. How long ago has this > "longstanding" behavior changed? Cannot parse that. Are you asking how old Icomplete is? Or when the last significant change in behavior was made to Icomplete? If so, I don't know the answer, but my guess would be that Icomplete is still essentially the same as it was designed to be, and it is quite old (decades). If you are really interested, you can do the archaeology to find the answers to what you are asking, whatever it is. > > It should be easy for each to get the behavior preferred, > > and even to switch to the other behavior. > > > > This is trivial to implement. What so much resistance to giving > > users the choice? Why so much insistence on bending Icomplete > > to be Ido-like for all? Users are free to use Ido if they like. > > Where's the beef? > > I believe most of the resistance is against your suggestion that the > minor mode with modified keybindings should be off by default. That's truly good to hear. So if we are agreed that users be able to easily toggle the behavior on/off, instead of telling them to go roll their own if they don't like the change, then let's move on to the question of the default: on or off. > If you hide nice things from users, some portion of users with never > find them. So, it hurts discoverability. Wonderful features have a way of being discovered, and I am sure this will have no problem in that regard. Discoverability seems a big deal when someone wants to announce their wonderful new feature - you want to make sure people don't miss the new 2014 car model, so you advertise it. Not needed here. Emacs advertises using NEWS, the manual, and menus. More important here should be leaving Icomplete to do its great job of passively showing help. I am in favor of keeping the traditional behavior by default. A non-Lisper who uses packages P and Q, which might bind some minibuffer keys, should not need to get out the Elisp manual to try to find a way to restore the bindings that P or Q provide, whenever Icomplete mode is turned on together with P or Q. By default, Icomplete should not change any minibuffer bindings. But whichever behavior is the default is far and away secondary to the matter of providing a quick toggle between the two behaviors. That is my primary concern. Even if we misguidedly let Icomplete impose bindings by default, a user should see in the Icomplete doc string that she can just toggle on or off a secondary mode that removes those bindings and restores whatever would be there otherwise. S?he should not be looking up the Lisp code of P, and digging into the Elisp manual, to find which keys to rebind and how, in order to get P's bindings each time. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-01-31 19:41 bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Drew Adams 2013-02-04 10:27 ` Jambunathan K 2013-02-04 11:20 ` Dmitry Gutov @ 2013-02-04 14:51 ` Stefan Monnier 2013-02-04 16:22 ` Drew Adams 2 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2013-02-04 14:51 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 > It is not kosher to bind such keys in the minibuffer in a general mode. Of course it is. Most modes do that. > Let users bind them if they like. Instead, we provide a default set. The user is still, as always, free to add or remove bindings. E.g. you might like to add (setq icomplete-minibuffer-map (make-sparse-keymap)) to your .emacs if you prefer the old behavior. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 14:51 ` Stefan Monnier @ 2013-02-04 16:22 ` Drew Adams 2013-02-04 16:43 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-04 16:22 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 13602 > > It is not kosher to bind such keys in the minibuffer in a > > general mode. > > Of course it is. Most modes do that. Icomplete is not a new mode. Its use has been to provide informative help. It has never interfered with minibuffer bindings in its long history. Even if Icomplete were new, we should separate the binding of keys out, making that optional. It should be easy to use Icomplete with all the existing minibuffer bindings. Introducing alternative minibuffer bindings for use with Icomplete mode is fine. But they should be optional. > > Let users bind them if they like. > > The user is still, as always, free to add or remove bindings. > E.g. you might like to add (setq icomplete-minibuffer-map > (make-sparse-keymap)) > to your .emacs if you prefer the old behavior. Make it _easier_ on users. Do what we've done for CUA mode and CUA selection mode. Let users easily separate the informative help aspect of Icomplete - what it has always provided, from the addition of Ido-like cycling. And do not have Icomplete trample minibuffer bindings by default. Let users opt in for that. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 16:22 ` Drew Adams @ 2013-02-04 16:43 ` Jambunathan K 2013-02-04 17:40 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-04 16:43 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 "Drew Adams" <drew.adams@oracle.com> writes: > And do not have Icomplete trample minibuffer bindings by default. Let users opt > in for that. Does Ido-like Icomplete mode interfere with any of your (existing?) libraries? If yes, then you make your case stronger. For overall good, you may want to describe how your libraries depend upon the "old" icomplete behaviour. Note that I have no opinion on whether cycling should be opt-in or opt-out, by default. -- ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 16:43 ` Jambunathan K @ 2013-02-04 17:40 ` Drew Adams 2013-02-05 2:35 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-04 17:40 UTC (permalink / raw) To: 'Jambunathan K'; +Cc: 13602 > > And do not have Icomplete trample minibuffer bindings by > > default. Let users opt in for that. > > Does Ido-like Icomplete mode interfere with any of your (existing?) > libraries? Yes, but it is irrelevant. I am not arguing wrt any other libraries. The argument is general. It is wrt emacs -Q and its normal, default minibuffer behavior. And it is general in that it is also wrt nearly any minibuffer behavior (not just emacs -Q), from nearly any package, whether it be distributed by Emacs (e.g. Ido, Viper) or not. There is nothing in my argument that relates specifically to any given package. Until now, Icomplete has simply aided users passively, by showing the possibile completions. It has not in any way changed the behavior of the user's interaction with the minibuffer (e.g. keys). That should continue to be the default behavior: let Icomplete inform about completions but not change the current minibuffer interaction (whatever that might be, emacs -Q or otherwise). Let Icomplete also offer an additional mode, like CUA does with CUA mode instead of CUA selection mode, whereby it binds some cycling keys. So much the better - I'm glad you provided this feature. > Note that I have no opinion on whether cycling should be opt-in or > opt-out, by default. I do. It should be opt-in, so that Icomplete preserves, by default, whatever minibuffer behavior is already present and preferred by the user. There are many different minibuffer behaviors besides emacs -Q and Ido. Some, like Viper and Ido, are very different from emacs -Q. Some are more similar to emacs -Q. The point is that a user's preferred minibuffer interaction should not be thrown to the wind just because s?he turns on Icomplete mode. And whether opt-in or opt-out, it should be trivial and clear for a user how to toggle to the other behavior. The code I sent lets you do that using a command/key. No fiddling with keymaps by users, etc. If users want to change which keys are used for Icomplete cycling, _then_ they can fiddle with the bindings. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-04 17:40 ` Drew Adams @ 2013-02-05 2:35 ` Jambunathan K 2013-02-05 4:29 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-05 2:35 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 "Drew Adams" <drew.adams@oracle.com> writes: >> > And do not have Icomplete trample minibuffer bindings by >> > default. Let users opt in for that. >> >> Does Ido-like Icomplete mode interfere with any of your (existing?) >> libraries? > > Yes, but it is irrelevant. How can you argue for a case without supporting documents? Why refuse the explicit call for evidence. Whatever arguments you provide may not be relevant to this bug per-se, but it will help others understand how bare-bones icomplete can be used. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-05 2:35 ` Jambunathan K @ 2013-02-05 4:29 ` Drew Adams 2013-02-05 23:19 ` Juri Linkov 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-05 4:29 UTC (permalink / raw) To: 'Jambunathan K'; +Cc: 13602 > >> Does Ido-like Icomplete mode interfere with any of your > >> (existing?) libraries? > > > > Yes, but it is irrelevant. I am not arguing wrt any other > > libraries. The argument is general. It is wrt emacs -Q > > and its normal, default minibuffer behavior. > > How can you argue for a case without supporting documents? > Why refuse the explicit call for evidence. It's not about me. It's not about any libraries I might use. I could as easily and as honestly have answered your question with "No, and it is irrelevant." I don't particularly or personally need any of the keys you propose to have Icomplete bind, for any other purpose. For my own use, the problem does not exist. I've already added a mode to separate the cycling behavior from the show-completions behavior - au choix. I sent the code for that, as an example. That's reasonable, IMO. It's about Emacs users generally, and Icomplete generally. Icomplete has played a useful role for a long time, usable in combination with emacs -Q and with any other code that binds any keys in the minibuffer. That's pretty darn useful. Icomplete's lack of key bindings is an important feature, one that lets it fit in. It is apparently this point that you are not getting. You appear to be focused on your new feature and not appreciating Icomplete for the simplicity it offers. That feature of getting along with others is now thrown to the wind because you want to add another feature that compromises it. All I am suggesting is that we keep that useful feature and provide your bells and whistles as an easy-to-use-easy-to-refuse option. What's wrong with that? It's about keeping Icomplete so that it plays well with emacs -Q and with any minibuffer key bindings that any user might have, bindings existing today or tomorrow, coming from anywhere. That should be the default. If Icomplete is now going to provide a mode where it adds its own bindings, which obviously could conflict with other bindings, then that mode should be optional, and preferably not be the default Icomplete behavior. Until now, Icomplete has not had a behavior wrt keys. You want to give it an Ido-like behavior. I say fine, make that an option, so the good ol' Icomplete, which imposes no key behavior, is still there as the default. I would have said the same thing if the proposal were to give Icomplete a Viper-like key behavior, or an Icicles-like key behavior, or an mcomplete.el key behavior, or a minibuffer-complete-cycle.el key behavior, or a cycle-mini.el key behavior, or a Helm key behavior, or a timid.el key behavior, or Suzy Creamcheese's custom minibuffer key behavior, or any other minibuffer key behavior. The point is to keep Icomplete simple and informational, having nothing to do with keys, so that it plays well with any completion minibuffer - by default. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-05 4:29 ` Drew Adams @ 2013-02-05 23:19 ` Juri Linkov 2013-02-06 3:42 ` Jambunathan K 2013-02-06 15:42 ` Stefan Monnier 0 siblings, 2 replies; 42+ messages in thread From: Juri Linkov @ 2013-02-05 23:19 UTC (permalink / raw) To: Drew Adams; +Cc: 13602, 'Jambunathan K' > I don't particularly or personally need any of the keys you propose to have > Icomplete bind, for any other purpose. I for one just disabled `icomplete-mode' in ~/.emacs when it got added ido keybindings, waiting in the hope that someone will implement `icomplete-mode-without-ido-keybindings' :-) Without ido keybindings `icomplete-mode' is useful to see all possible completions to be able to decide what the minimal length of the completion string is sufficient to type. For instance, with the intention to run `grep-find' typing `M-x gr' shows "gr(ep){| -find | -mode}" that hints that the shortest string to type is "gr-f" which could be remembered as the shortest alias for "grep-find". ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-05 23:19 ` Juri Linkov @ 2013-02-06 3:42 ` Jambunathan K 2013-02-06 10:24 ` Juri Linkov 2013-02-06 15:42 ` Stefan Monnier 1 sibling, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-06 3:42 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602 Juri Linkov <juri@jurta.org> writes: >> I don't particularly or personally need any of the keys you propose to have >> Icomplete bind, for any other purpose. > > I for one just disabled `icomplete-mode' in ~/.emacs when it got > added ido keybindings, waiting in the hope that someone will implement > `icomplete-mode-without-ido-keybindings' :-) > > Without ido keybindings `icomplete-mode' is useful to see all possible > completions to be able to decide what the minimal length of the > completion string is sufficient to type. I would have started this paragraph with: "With or without ido keybindings". Ido keybindings only adds cycling, it doesn't mess with the display. It is not clear to me how "Without ido keybindings" makes it "useful to see all completions" . If you want bigger real-estate you can tweak the icomplete-separator option. > For instance, with the intention to run `grep-find' typing `M-x gr' shows > "gr(ep){| -find | -mode}" that hints that the shortest string to type is > "gr-f" which could be remembered as the shortest alias for "grep-find". ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 3:42 ` Jambunathan K @ 2013-02-06 10:24 ` Juri Linkov 2013-02-06 13:31 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Juri Linkov @ 2013-02-06 10:24 UTC (permalink / raw) To: Jambunathan K; +Cc: 13602 > I would have started this paragraph with: "With or without ido > keybindings". Ido keybindings only adds cycling, it doesn't mess with > the display. Yes, "with or without ido keybindings", icomplete-mode is a standalone feature separate from ido keybindings. As the node (info "(emacs) Minor Modes") says: * Icomplete mode displays an indication of available completions when you are in the minibuffer and completion is active. *Note Completion Options::. and also (info "(emacs) Completion Options"): Icomplete mode presents a constantly-updated display that tells you what completions are available for the text you've entered so far. and the Commentary section in icomplete.el: ;; Prospective completions are concisely indicated within the ;; minibuffer itself, with each successive keystroke. There is nothing in documentation that suggests icomplete-mode was intended to add ido keybindings. If you want to create its submode implementing a new feature that makes it work like `ido', why not give it a new name like `icomplete-ido-mode'? ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 10:24 ` Juri Linkov @ 2013-02-06 13:31 ` Jambunathan K 2013-02-06 15:27 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-06 13:31 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602 Juri Linkov <juri@jurta.org> writes: >> I would have started this paragraph with: "With or without ido >> keybindings". Ido keybindings only adds cycling, it doesn't mess with >> the display. > > Yes, "with or without ido keybindings", icomplete-mode is a standalone feature > separate from ido keybindings. As the node (info "(emacs) Minor Modes") says: > > * Icomplete mode displays an indication of available completions when > you are in the minibuffer and completion is active. *Note > Completion Options::. > > and also (info "(emacs) Completion Options"): > > Icomplete mode presents a constantly-updated display that tells you > what completions are available for the text you've entered so far. > > and the Commentary section in icomplete.el: > > ;; Prospective completions are concisely indicated within the > ;; minibuffer itself, with each successive keystroke. > > There is nothing in documentation that suggests icomplete-mode > was intended to add ido keybindings. I am amused by the last paragraph. I don't think the author of Icomplete was a clarivoyant. You seem to make a mistaken assumption that if something is left un-said then that something ceases to exist. > If you want to create its submode implementing a new feature > that makes it work like `ido', why not give it a new name like > `icomplete-ido-mode'? Let me remind everyone: I made a proposal and it sailed through. Drew has made a proposal and you have chimed in. It is for the maintainers to make a call on what to do about it. I don't think my opinion matters here (much). Jambunathan K. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 13:31 ` Jambunathan K @ 2013-02-06 15:27 ` Drew Adams 0 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-06 15:27 UTC (permalink / raw) To: 'Jambunathan K', 'Juri Linkov'; +Cc: 13602 > Let me remind everyone: I made a proposal and it sailed through. > Drew has made a proposal and you have chimed in. It is for the > maintainers to make a call on what to do about it. I don't think my > opinion matters here (much). Jamunathan, I don't understand your resistance to making your keybindings optional, and making it simple for a user to toggle them on/off. We haven't seen any argument supporting such resistance, AFAICT. IOW, I don't think that anyone (not I, in any case) opposes the addition of a feature that allows keys to be bound to provide Ido-like cycling. All we (I, at least) are requesting is that this be user-controlled in a simple (trivial) way. Why is that too much to ask, in your opinion (which does matter, obviously)? Requiring users to fiddle with the minibuffer keymaps using Lisp is a non response. A user might use one or more additional packages that change or add minibuffer bindings, and s?he should not have to try to code up a way to restore whatever bindings would have been in effect without yours. Even with emacs -Q, users should not need to know Lisp to be able to quickly undo your bindings. Just please make it easy on users to get back the Icomplete behavior they have long enjoyed and might still prefer. And please keep that longstanding behavior as the default one. I sense that that too is what Juri is underlining by quoting descriptions of the original behavior and the intentions behind it. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-05 23:19 ` Juri Linkov 2013-02-06 3:42 ` Jambunathan K @ 2013-02-06 15:42 ` Stefan Monnier 2013-02-06 15:49 ` Drew Adams 2013-02-06 16:02 ` Stefan Monnier 1 sibling, 2 replies; 42+ messages in thread From: Stefan Monnier @ 2013-02-06 15:42 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602, 'Jambunathan K' > I for one just disabled `icomplete-mode' in ~/.emacs when it got > added ido keybindings, waiting in the hope that someone will implement > `icomplete-mode-without-ido-keybindings' :-) (setq icomplete-minibuffer-map (make-sparse-keymap)) should do it. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 15:42 ` Stefan Monnier @ 2013-02-06 15:49 ` Drew Adams 2013-02-06 16:02 ` Stefan Monnier 1 sibling, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-06 15:49 UTC (permalink / raw) To: 'Stefan Monnier', 'Juri Linkov' Cc: 13602, 'Jambunathan K' > > I for one just disabled `icomplete-mode' in ~/.emacs when it got > > added ido keybindings, waiting in the hope that someone > > will implement `icomplete-mode-without-ido-keybindings' :-) > > (setq icomplete-minibuffer-map (make-sparse-keymap)) > should do it. Here's the point: Users should not have to do that. Give them a simple toggle command, so they don't need to know Lisp and dig into the Icomplete or other code to figure that out and fix things. And please turn off the bindings by default. What's the big deal? This should be a no-brainer. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 15:42 ` Stefan Monnier 2013-02-06 15:49 ` Drew Adams @ 2013-02-06 16:02 ` Stefan Monnier 2013-02-06 23:45 ` Juri Linkov 1 sibling, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2013-02-06 16:02 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602, 'Jambunathan K' >> I for one just disabled `icomplete-mode' in ~/.emacs when it got >> added ido keybindings, waiting in the hope that someone will implement >> `icomplete-mode-without-ido-keybindings' :-) > (setq icomplete-minibuffer-map (make-sparse-keymap)) > should do it. BTW, which of those keybindings do you find inconvenient? Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 16:02 ` Stefan Monnier @ 2013-02-06 23:45 ` Juri Linkov 2013-02-07 3:51 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Juri Linkov @ 2013-02-06 23:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13602, 'Jambunathan K' >>> I for one just disabled `icomplete-mode' in ~/.emacs when it got >>> added ido keybindings, waiting in the hope that someone will implement >>> `icomplete-mode-without-ido-keybindings' :-) >> (setq icomplete-minibuffer-map (make-sparse-keymap)) >> should do it. > > BTW, which of those keybindings do you find inconvenient? `C-r' like in bash is useful to search for previous input in the history. This is especially useful for frequently used long command names for which it's difficult to find the shortest completion alias and remember it, e.g. for the command `gnus-read-ephemeral-emacs-bug-group' re-invoking it from the history is easy with just `M-x C-r gn RET RET'. Another frequently used case is using `C-s C-w C-w' to put the completed string into the search ring, exit Isearch, exit the minibuffer and search the same string from the ring in another buffer with `C-s C-s'. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-06 23:45 ` Juri Linkov @ 2013-02-07 3:51 ` Jambunathan K 2013-02-07 7:50 ` Juri Linkov 0 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-07 3:51 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602 Juri Linkov <juri@jurta.org> writes: >>>> I for one just disabled `icomplete-mode' in ~/.emacs when it got >>>> added ido keybindings, waiting in the hope that someone will implement >>>> `icomplete-mode-without-ido-keybindings' :-) >>> (setq icomplete-minibuffer-map (make-sparse-keymap)) >>> should do it. >> >> BTW, which of those keybindings do you find inconvenient? > > `C-r' like in bash is useful to search for previous input in the history. > This is especially useful for frequently used long command names > for which it's difficult to find the shortest completion alias and > remember it, e.g. for the command `gnus-read-ephemeral-emacs-bug-group' > re-invoking it from the history is easy with just `M-x C-r gn RET RET'. `completion-all-sorted-completions' prefers recent input history. Once you have `gnus-read-ephemeral-emacs-bug-group' in the command history, it is likely to be the first of the few completions which you can pick with one or more C-s-es. One doesn't need to rely on traditional "C-r" exclusively to accomplish the above work flow. > Another frequently used case is using `C-s C-w C-w' to put the completed > string into the search ring, exit Isearch, exit the minibuffer and > search the same string from the ring in another buffer with `C-s C-s'. Can you tell me why this is "frequent"? May be you use this to jump to a command name in a *.el file. May be, there is a stronger case for "C-s" to be re-considered. Whatever is decided, I would expect that ido and icomplete share the same keys for cycling back and forth. -- ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 3:51 ` Jambunathan K @ 2013-02-07 7:50 ` Juri Linkov 2013-02-07 10:24 ` Jambunathan K 2013-02-07 14:17 ` Stefan Monnier 0 siblings, 2 replies; 42+ messages in thread From: Juri Linkov @ 2013-02-07 7:50 UTC (permalink / raw) To: Jambunathan K; +Cc: 13602 > `completion-all-sorted-completions' prefers recent input history. Once > you have `gnus-read-ephemeral-emacs-bug-group' in the command history, > it is likely to be the first of the few completions which you can pick > with one or more C-s-es. > > One doesn't need to rely on traditional "C-r" exclusively to accomplish > the above work flow. IIUC, it matches only prefixes, whereas traditional Isearch `C-r' can also match in the middle of the command name in the history. When I tried now `icomplete-backward-completions' currently bound to `C-r', I discovered that it is broken. It fails with the error: Debugger entered--Lisp error: (wrong-type-argument listp 0) cdr(0) (setcdr last-but-one (cdr last)) (progn (setcdr last-but-one (cdr last)) ...) (if last (progn (setcdr last-but-one (cdr last)) ...)) (let* ((comps (completion-all-sorted-completions)) (last (cdr last-but-one))) ...) icomplete-backward-completions() call-interactively(icomplete-backward-completions nil nil) read-from-minibuffer("M-x " nil ... nil extended-command-history nil nil) completing-read-default("M-x " ... commandp t nil extended-command-history nil nil) completing-read("M-x " ... commandp t nil extended-command-history) read-extended-command() byte-code("..." [current-prefix-arg read-extended-command] 2) call-interactively(execute-extended-command nil nil) The full test case: 0. emacs -Q 1. M-x icomplete-mode RET 2. M-x icomplete-m C-r Does this mean that other users of `icomplete-mode' like me disabled `icomplete-mode' in their .emacs after it began overriding Isearch keys, so this feature remained untested and the bug remained unnoticed for the long time (2 months)? I won't be surprised if this is the real reason, because traditional Isearch C-s and C-r is useful in the minibuffer. OTOH, I believe the users of `icomplete-mode' might like the new feature provided by the new commands `icomplete-forward-completions' and `icomplete-backward-completions' only when it leaves intact the traditional Isearch keybindings C-s and C-r. Let's face the root of the problem: abusing C-s and C-r keys in ido was a poor choice in the first place that paved the road to future conflicts. Are there know alternatives to C-s and C-r among the ido users? I see that ido.el mentions the right and left arrow keys. Could they be used with some modifiers? ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 7:50 ` Juri Linkov @ 2013-02-07 10:24 ` Jambunathan K 2013-02-08 7:55 ` Juri Linkov 2013-02-07 14:17 ` Stefan Monnier 1 sibling, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-07 10:24 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602 [-- Attachment #1: Type: text/plain, Size: 874 bytes --] Juri Linkov <juri@jurta.org> writes: >> `completion-all-sorted-completions' prefers recent input history. Once >> you have `gnus-read-ephemeral-emacs-bug-group' in the command history, >> it is likely to be the first of the few completions which you can pick >> with one or more C-s-es. >> >> One doesn't need to rely on traditional "C-r" exclusively to accomplish >> the above work flow. > > IIUC, it matches only prefixes, whereas traditional Isearch `C-r' > can also match in the middle of the command name in the history. > > When I tried now `icomplete-backward-completions' currently bound to `C-r', > I discovered that it is broken. It fails with the error: > > Debugger entered--Lisp error: (wrong-type-argument listp 0) > cdr(0) > (setcdr last-but-one (cdr last)) > > The full test case: > > 0. emacs -Q > 1. M-x icomplete-mode RET > 2. M-x icomplete-m C-r [-- Attachment #2: icomplete.el.diff --] [-- Type: text/plain, Size: 1393 bytes --] === modified file 'lisp/ChangeLog' --- lisp/ChangeLog 2013-02-07 08:50:04 +0000 +++ lisp/ChangeLog 2013-02-07 10:11:32 +0000 @@ -1,3 +1,8 @@ +2013-02-07 Jambunathan K <kjambunathan@gmail.com> + + * icomplete.el (icomplete-forward-completions) + (icomplete-backward-completions): Handle corner case (bug#13602). + 2013-02-07 Michael Albinus <michael.albinus@gmx.de> * vc/vc-hooks.el (vc-find-file-hook): `buffer-file-truename' can === modified file 'lisp/icomplete.el' --- lisp/icomplete.el 2013-01-04 08:20:49 +0000 +++ lisp/icomplete.el 2013-02-07 10:01:09 +0000 @@ -167,8 +167,9 @@ Second entry becomes the first and can b (interactive) (let* ((comps (completion-all-sorted-completions)) (last (last comps))) + (when comps (setcdr last (cons (car comps) (cdr last))) - (completion--cache-all-sorted-completions (cdr comps)))) + (completion--cache-all-sorted-completions (cdr comps))))) (defun icomplete-backward-completions () "Step backward completions by one entry. @@ -178,7 +179,7 @@ Last entry becomes the first and can be (let* ((comps (completion-all-sorted-completions)) (last-but-one (last comps 2)) (last (cdr last-but-one))) - (when last + (when (consp last) ; Atleast two elements in comps (setcdr last-but-one (cdr last)) (push (car last) comps) (completion--cache-all-sorted-completions comps)))) [-- Attachment #3: Type: text/plain, Size: 1427 bytes --] > Does this mean that other users of `icomplete-mode' like me disabled > `icomplete-mode' in their .emacs after it began overriding Isearch keys, > so this feature remained untested and the bug remained unnoticed > for the long time (2 months)? I won't be surprised if this is > the real reason, because traditional Isearch C-s and C-r is useful > in the minibuffer. Interesting to learn that disabling of `icomplete-mode' might have been an un-intentional side-effect rather than a deliberate act. Interesting to see how this exchange is developing. > OTOH, I believe the users of `icomplete-mode' might like the new feature > provided by the new commands `icomplete-forward-completions' and > `icomplete-backward-completions' only when it leaves intact the > traditional Isearch keybindings C-s and C-r. Let's have best of both worlds rather than label the unknown and strange world as hell. > Let's face the root of the problem: abusing C-s and C-r keys in ido was > a poor choice in the first place that paved the road to future > conflicts. Fair statement. > Are there know alternatives to C-s and C-r among the ido users? I use C-s and C-r myself. > I see that ido.el mentions the right and left arrow keys. > Could they be used with some modifiers? This would mean that my right hand is leaving the home row. Any suggestions ... ISearch map is really a big rock that leaves little room for even pebbles... ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 10:24 ` Jambunathan K @ 2013-02-08 7:55 ` Juri Linkov 2013-02-08 16:55 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Juri Linkov @ 2013-02-08 7:55 UTC (permalink / raw) To: Jambunathan K; +Cc: 13602 > +2013-02-07 Jambunathan K <kjambunathan@gmail.com> > + > + * icomplete.el (icomplete-forward-completions) > + (icomplete-backward-completions): Handle corner case (bug#13602). Thanks, your fix is now installed in trunk. > How about C-S-s and C-S-r? I just need to have Shift key depressed, > which is fine with me. > > (define-key map [?\C-\S-s] 'icomplete-forward-completions) > (define-key map [?\C-\S-r] 'icomplete-backward-completions) Such compromise keys do not do any good neither to ido users nor to non-ido users. Better would be to add an option like `icomplete-enable-ido-keys' that when set to t will define ido-specific bindings on `C-s' and `C-r'. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 7:55 ` Juri Linkov @ 2013-02-08 16:55 ` Drew Adams 0 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-08 16:55 UTC (permalink / raw) To: 'Juri Linkov', 'Jambunathan K'; +Cc: 13602 > > How about C-S-s and C-S-r? I just need to have Shift key depressed, > > which is fine with me. > > > > (define-key map [?\C-\S-s] 'icomplete-forward-completions) > > (define-key map [?\C-\S-r] 'icomplete-backward-completions) > > Such compromise keys do not do any good neither to ido users > nor to non-ido users. Agreed. But Ido users presumably do not need Icomplete anyway. It is non-Ido users that we should be concerned about for Icomplete. > Better would be to add an option like `icomplete-enable-ido-keys' that > when set to t will define ido-specific bindings on `C-s' and `C-r'. Yes, but without "ido" in the name. It is about enabling keys (any keys) for Icomplete. It is not about enabling Ido keys for Icomplete. The keys to use by default can be whatever you like, but they should be specific to Icomplete (i.e., in its own, independent keymap, as now). I.e., even if the keys used by default are identical to those used in Ido by default, there should be no other connection. Since users will be free to change them in either place separately, the option name should be unrelated to Ido. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 7:50 ` Juri Linkov 2013-02-07 10:24 ` Jambunathan K @ 2013-02-07 14:17 ` Stefan Monnier 2013-02-07 15:45 ` Jambunathan K ` (2 more replies) 1 sibling, 3 replies; 42+ messages in thread From: Stefan Monnier @ 2013-02-07 14:17 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602, Jambunathan K > Does this mean that other users of `icomplete-mode' like me disabled > `icomplete-mode' in their .emacs after it began overriding Isearch keys, > so this feature remained untested and the bug remained unnoticed > for the long time (2 months)? I don't think so: the commands work(ed) in "most" cases. > I won't be surprised if this is the real reason, because traditional > Isearch C-s and C-r is useful in the minibuffer. I suspect most users of icomplete who didn't follow the emacs-devel list just didn't notice the change because they never/rarely use C-s and C-r in the minibuffer. > Let's face the root of the problem: abusing C-s and C-r keys in ido was > a poor choice in the first place that paved the road to future conflicts. I don't know if it was a poor choice, given that IDO tends to move away from the idea that the minibuffer is just a normal buffer with normal editing commands. > I see that ido.el mentions the right and left arrow keys. > Could they be used with some modifiers? I think it's a good idea to try and use something else than C-s C-r, since admittedly they collide with existing usage. But the problem is indeed to find other bindings. We could use arrows with modifiers: by default, M-left and C-left do the same thing, so we could use either C-left/C-right or M-left/M-right. Another option that stays closer to IDO (and to home row) is M-s and M-r (M-r's move-to-window-line-top-bottom is fairly useless in the minibuffer, but M-s is normally a prefix key for search commands, so it's not ideal, tho it's less severe than overriding C-s). Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 14:17 ` Stefan Monnier @ 2013-02-07 15:45 ` Jambunathan K 2013-02-07 16:50 ` Stefan Monnier 2013-02-07 21:32 ` Drew Adams 2013-02-08 7:59 ` Juri Linkov 2 siblings, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-07 15:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13602 Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I see that ido.el mentions the right and left arrow keys. >> Could they be used with some modifiers? > > I think it's a good idea to try and use something else than C-s C-r, > since admittedly they collide with existing usage. But the problem is > indeed to find other bindings. > > We could use arrows with modifiers: by default, M-left and C-left do the > same thing, so we could use either C-left/C-right or M-left/M-right. > > Another option that stays closer to IDO (and to home row) is M-s and M-r > (M-r's move-to-window-line-top-bottom is fairly useless in the > minibuffer, but M-s is normally a prefix key for search commands, so > it's not ideal, tho it's less severe than overriding C-s). How about C-S-s and C-S-r? I just need to have Shift key depressed, which is fine with me. (define-key map [?\C-\S-s] 'icomplete-forward-completions) (define-key map [?\C-\S-r] 'icomplete-backward-completions) ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 15:45 ` Jambunathan K @ 2013-02-07 16:50 ` Stefan Monnier 2013-02-10 4:15 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2013-02-07 16:50 UTC (permalink / raw) To: Jambunathan K; +Cc: 13602 > How about C-S-s and C-S-r? I just need to have Shift key depressed, > which is fine with me. > (define-key map [?\C-\S-s] 'icomplete-forward-completions) > (define-key map [?\C-\S-r] 'icomplete-backward-completions) I'm not very much in favor: - in my environment, C-S-r works but C-S-s is not received by Emacs (maybe XFCE catches it?). - it won't work in ttys. - I find it cumbersome to type. None of them are deal breakers. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 16:50 ` Stefan Monnier @ 2013-02-10 4:15 ` Jambunathan K 0 siblings, 0 replies; 42+ messages in thread From: Jambunathan K @ 2013-02-10 4:15 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13602 Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> How about C-S-s and C-S-r? I just need to have Shift key depressed, >> which is fine with me. > >> (define-key map [?\C-\S-s] 'icomplete-forward-completions) >> (define-key map [?\C-\S-r] 'icomplete-backward-completions) > > I'm not very much in favor: > - in my environment, C-S-r works but C-S-s is not received by Emacs > (maybe XFCE catches it?). > - it won't work in ttys. > - I find it cumbersome to type. > None of them are deal breakers. We seem to be settling on C-left and C-right. That said, how about C-, and C-. (C-< and C->) No need to move away from Home Row and the less/greater symbols can serve as directional cues for rote learning. > > > Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 14:17 ` Stefan Monnier 2013-02-07 15:45 ` Jambunathan K @ 2013-02-07 21:32 ` Drew Adams 2013-02-08 7:59 ` Juri Linkov 2 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-07 21:32 UTC (permalink / raw) To: 'Stefan Monnier', 'Juri Linkov' Cc: 13602, 'Jambunathan K' Ironic. The imposition of key bindings on Icomplete is being promoted by Ido enthusiasts who have no real need for it since they use Ido, which does the same thing. Who does use Icomplete, and who will thus receive this gift not needed by its donors? Users who _do_ edit minibuffer contents. Icomplete is really for non-Ido users. It is used in an ordinary, non-Ido minibuffer. Imposing Ido keys on it (as opposed to just offering them as an option), and thus taking away normal editing keys, is questionable, if not misquided. Why this is being promoted so forcefully by people who presumably will not use Icomplete is a wonder. It makes little difference which keys are chosen for these bindings. Whatever they are, they can conflict with keys used otherwise in the minibuffer, whether those keys come from bare emacs -Q or from some other code. I don't understand the refusal to let users choose easily whether they want Icomplete to bind keys. What's the problem with that? I've asked this several times and not once gotten an answer. Why the avoidance to confront the question head-on? Instead of presenting reasons why this choice should be refused (only silence there so far), there are attempts to divert the argument to how particular keys are used - essentially a red herring. When Juri mentions C-r and C-s, we get a lecture on how one can work around the problem, Ido-style. > One doesn't need to rely on traditional "C-r" exclusively to > accomplish the above work flow. Need? Rely? Exclusively? Shades of "Let them eat cake". Ultimately, we get some admission that maybe C-s and C-r are not the best choices after all... So the diversion turns to a search for other keys (C-S-s...). It does not matter here how Juri uses C-s or any other key - whether he really "needs" to or how frequently he does so. It does not matter whether Ido users have found some other nifty way to accomplish the same thing as this or that ordinary editing practice. Some users _do_ edit, search, copy, and otherwise do things to their minibuffer input. And there is _no reason_ to try to shoehorn all such practice into an Ido shoe. No reason to present workarounds demonstrating that you can really do whatever you want in spite of the imposition of Ido keys. No need for any of that - just make the bindings optional, please. Ido does not use the minibuffer in the usual way at all. Its keys and its behavior are special, unusual, atypical for Emacs. But more importantly, the problem is not this or that key. The problem is binding any keys at all and not giving users a simple way to do without such bindings. How about it? Why not give users an option, and a toggle command? ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-07 14:17 ` Stefan Monnier 2013-02-07 15:45 ` Jambunathan K 2013-02-07 21:32 ` Drew Adams @ 2013-02-08 7:59 ` Juri Linkov 2013-02-08 15:40 ` Stefan Monnier 2 siblings, 1 reply; 42+ messages in thread From: Juri Linkov @ 2013-02-08 7:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13602, Jambunathan K > I think it's a good idea to try and use something else than C-s C-r, > since admittedly they collide with existing usage. But the problem is > indeed to find other bindings. > > We could use arrows with modifiers: by default, M-left and C-left do the > same thing, so we could use either C-left/C-right or M-left/M-right. I perceive the `icomplete-mode' feature as a way to select a completion without opening the list of completions in the *Completions* buffer. Since the list of completions can be opened from the minibuffer by typing <prior> or `M-v' (`switch-to-completions') and selecting a completion with <left> `previous-completion' and <right> `next-completion' (whereas `C-f' and `C-b' retain their traditional keybindings), e.g. to select `list-buffers' one could type: `M-x list- <prior> <right> <right> RET' so it would be reasonable to use something similar in icomplete: `M-x list- <C-right> <C-right> C-j' (the advantage is that the user doesn't have to release the Control key) or also `M-x list- <C-right> <C-right> C-RET' (interesting that `C-RET' is already translated to `C-j' on ttys by default but not on X, so a separate keybinding is necessary for C-RET on X for `minibuffer-force-complete-and-exit' currently bound to `C-j'.) ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 7:59 ` Juri Linkov @ 2013-02-08 15:40 ` Stefan Monnier 2013-02-08 17:00 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Stefan Monnier @ 2013-02-08 15:40 UTC (permalink / raw) To: Juri Linkov; +Cc: 13602, Jambunathan K > `M-x list- <C-right> <C-right> C-RET' So you're voting for C-left/C-right? OK, noted. > (interesting that `C-RET' is already translated to `C-j' on ttys by default > but not on X, In my xterm, when I hit C-RET I get "<C-return> is undefined", so it's not the case for all ttys. Stefan ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 15:40 ` Stefan Monnier @ 2013-02-08 17:00 ` Drew Adams 2013-02-08 17:11 ` Jambunathan K 0 siblings, 1 reply; 42+ messages in thread From: Drew Adams @ 2013-02-08 17:00 UTC (permalink / raw) To: 'Stefan Monnier', 'Juri Linkov' Cc: 13602, 'Jambunathan K' > > `M-x list- <C-right> <C-right> C-RET' > > So you're voting for C-left/C-right? OK, noted. Also not great. Removes two useful editing keys from the minibuffer (`backward-word', `forward-word'). But again, if the use of keys is optional and easily toggled, and especially if it is turned off by default, then it doesn't matter so much which keys you choose. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 17:00 ` Drew Adams @ 2013-02-08 17:11 ` Jambunathan K 2013-02-08 17:28 ` Drew Adams 2013-02-13 14:42 ` Jambunathan K 0 siblings, 2 replies; 42+ messages in thread From: Jambunathan K @ 2013-02-08 17:11 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 "Drew Adams" <drew.adams@oracle.com> writes: >> > `M-x list- <C-right> <C-right> C-RET' >> >> So you're voting for C-left/C-right? OK, noted. > > Also not great. Removes two useful editing keys from the minibuffer > (`backward-word', `forward-word'). M-x where-is RET tells me there is an escape route. backward-word is on M-b, ESC <left> forward-word is on M-f, ESC <right> > But again, if the use of keys is optional and easily toggled, and especially if > it is turned off by default, then it doesn't matter so much which keys you > choose. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 17:11 ` Jambunathan K @ 2013-02-08 17:28 ` Drew Adams 2013-02-13 14:42 ` Jambunathan K 1 sibling, 0 replies; 42+ messages in thread From: Drew Adams @ 2013-02-08 17:28 UTC (permalink / raw) To: 'Jambunathan K'; +Cc: 13602 > >> So you're voting for C-left/C-right? OK, noted. > > > > Also not great. Removes two useful editing keys from > > the minibuffer (`backward-word', `forward-word'). > > M-x where-is RET tells me there is an escape route. > backward-word is on M-b, ESC <left> > forward-word is on M-f, ESC <right> More workaround advice. But yes, these keys are so useful that emacs -Q binds them by default to multiple key sequences. Users have various use patterns. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-08 17:11 ` Jambunathan K 2013-02-08 17:28 ` Drew Adams @ 2013-02-13 14:42 ` Jambunathan K 2016-04-28 22:25 ` Lars Ingebrigtsen 1 sibling, 1 reply; 42+ messages in thread From: Jambunathan K @ 2013-02-13 14:42 UTC (permalink / raw) To: Drew Adams; +Cc: 13602 Jambunathan K <kjambunathan@gmail.com> writes: > "Drew Adams" <drew.adams@oracle.com> writes: > >>> > `M-x list- <C-right> <C-right> C-RET' >>> >>> So you're voting for C-left/C-right? OK, noted. >> >> Also not great. Removes two useful editing keys from the minibuffer >> (`backward-word', `forward-word'). > > M-x where-is RET tells me there is an escape route. > > backward-word is on M-b, ESC <left> > forward-word is on M-f, ESC <right> I have opened a new bug and put my offerings there. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13708 >> But again, if the use of keys is optional and easily toggled, and especially if >> it is turned off by default, then it doesn't matter so much which keys you >> choose. ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2013-02-13 14:42 ` Jambunathan K @ 2016-04-28 22:25 ` Lars Ingebrigtsen 2016-04-29 16:05 ` Drew Adams 0 siblings, 1 reply; 42+ messages in thread From: Lars Ingebrigtsen @ 2016-04-28 22:25 UTC (permalink / raw) To: Jambunathan K; +Cc: 13602, 'Stefan Monnier' I think the conclusion here was that we do not want to change the key bindings for icomplete. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 42+ messages in thread
* bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode 2016-04-28 22:25 ` Lars Ingebrigtsen @ 2016-04-29 16:05 ` Drew Adams 0 siblings, 0 replies; 42+ messages in thread From: Drew Adams @ 2016-04-29 16:05 UTC (permalink / raw) To: Lars Ingebrigtsen, Jambunathan K; +Cc: 13602, Stefan Monnier > I think the conclusion here was that we do not want to > change the key bindings for icomplete. Amazing conclusion to be drawn from this discussion. Oh well. ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2016-04-29 16:05 UTC | newest] Thread overview: 42+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-31 19:41 bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode Drew Adams 2013-02-04 10:27 ` Jambunathan K 2013-02-04 16:02 ` Drew Adams 2013-02-04 16:36 ` Jambunathan K 2013-02-04 17:34 ` Drew Adams 2013-02-04 11:20 ` Dmitry Gutov 2013-02-04 16:16 ` Drew Adams 2013-02-04 22:04 ` Dmitry Gutov 2013-02-04 23:33 ` Drew Adams 2013-02-04 14:51 ` Stefan Monnier 2013-02-04 16:22 ` Drew Adams 2013-02-04 16:43 ` Jambunathan K 2013-02-04 17:40 ` Drew Adams 2013-02-05 2:35 ` Jambunathan K 2013-02-05 4:29 ` Drew Adams 2013-02-05 23:19 ` Juri Linkov 2013-02-06 3:42 ` Jambunathan K 2013-02-06 10:24 ` Juri Linkov 2013-02-06 13:31 ` Jambunathan K 2013-02-06 15:27 ` Drew Adams 2013-02-06 15:42 ` Stefan Monnier 2013-02-06 15:49 ` Drew Adams 2013-02-06 16:02 ` Stefan Monnier 2013-02-06 23:45 ` Juri Linkov 2013-02-07 3:51 ` Jambunathan K 2013-02-07 7:50 ` Juri Linkov 2013-02-07 10:24 ` Jambunathan K 2013-02-08 7:55 ` Juri Linkov 2013-02-08 16:55 ` Drew Adams 2013-02-07 14:17 ` Stefan Monnier 2013-02-07 15:45 ` Jambunathan K 2013-02-07 16:50 ` Stefan Monnier 2013-02-10 4:15 ` Jambunathan K 2013-02-07 21:32 ` Drew Adams 2013-02-08 7:59 ` Juri Linkov 2013-02-08 15:40 ` Stefan Monnier 2013-02-08 17:00 ` Drew Adams 2013-02-08 17:11 ` Jambunathan K 2013-02-08 17:28 ` Drew Adams 2013-02-13 14:42 ` Jambunathan K 2016-04-28 22:25 ` Lars Ingebrigtsen 2016-04-29 16:05 ` Drew Adams
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.