all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>,
	"'Juri Linkov'" <juri@jurta.org>
Cc: 13602@debbugs.gnu.org, 'Jambunathan K' <kjambunathan@gmail.com>
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Thu, 7 Feb 2013 13:32:31 -0800	[thread overview]
Message-ID: <34B98B513D9349CA9C8819AE35F22D7A@us.oracle.com> (raw)
In-Reply-To: <jwvtxpocjcw.fsf-monnier+emacs@gnu.org>

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?







  parent reply	other threads:[~2013-02-07 21:32 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
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 [this message]
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=34B98B513D9349CA9C8819AE35F22D7A@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=13602@debbugs.gnu.org \
    --cc=juri@jurta.org \
    --cc=kjambunathan@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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.