all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Jambunathan K'" <kjambunathan@gmail.com>
Cc: 13602@debbugs.gnu.org
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Mon, 4 Feb 2013 09:40:50 -0800	[thread overview]
Message-ID: <20DF11E25EE542A1A334DA1FDB79F77B@us.oracle.com> (raw)
In-Reply-To: <87zjzk112u.fsf@gmail.com>

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






  reply	other threads:[~2013-02-04 17:40 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20DF11E25EE542A1A334DA1FDB79F77B@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=13602@debbugs.gnu.org \
    --cc=kjambunathan@gmail.com \
    /path/to/YOUR_REPLY

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

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