unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
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: Thu, 07 Feb 2013 09:50:10 +0200	[thread overview]
Message-ID: <87a9rgo959.fsf@mail.jurta.org> (raw)
In-Reply-To: <87txpon5mk.fsf@gmail.com> (Jambunathan K.'s message of "Thu, 07 Feb 2013 09:21:31 +0530")

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





  reply	other threads:[~2013-02-07  7:50 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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87a9rgo959.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).