bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - mak


From: Jambunathan K
Subject: bug#13602: 24.3.50; remove bindings for `icomplete-minibuffer-map' - make a separate mode
Date: Thu, 07 Feb 2013 15:54:55 +0530
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Juri Linkov <address@hidden> 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

=== 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  <address@hidden>
+
+       * icomplete.el (icomplete-forward-completions)
+       (icomplete-backward-completions): Handle corner case (bug#13602).
+
 2013-02-07  Michael Albinus  <address@hidden>
 
        * 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))))

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]