bug#5724: 23.1.94; ido bug in next match

bug#5724: 23.1.94; ido bug in next match

[Leo]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

In ido mode, C-s rotate the matches. The following steps exhibits a
delicate bug which seemingly causes the matches to re-order.

1. Emacs -q -l long-list.el (attached)
   take a look at the first 4 matches in the minibuffer
2. C-s

Normally you expect C-s to get you one step closer to the fourth item
but it just pushes it one step further in this case.

This is also reproducible with the ido.el included in Emacs 22.

It may have something to do with prefix-matches, matches, suffix-mathes
in ido-set-matches-1.

BTW, in my local copy of ido.el I have integrated recentf into it so ido
automatically pulls in visited files when switching buffers and the user
input does not match any. I have a long recentf-list.


[-- Attachment #2: long-list.el --]
[-- Type: application/emacs-lisp, Size: 7654 bytes --]

[-- Attachment #3: Type: text/plain, Size: 608 bytes --]


In GNU Emacs 23.1.94.1 (x86_64-apple-darwin10.2.0, Carbon Version 1.6.0 AppKit 1038.25)
 of 2010-03-14 on Victoria.local
Windowing system distributor `Apple Inc.', version 10.6.2
configured using `configure  '--prefix=/usr/local/unix/emacs' '--with-mac' 'CFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

bug#5724: 23.1.94; ido bug in next match

[Christian Dietrich]

Hi,
i can reproduce your bug here with emacs 23.1, and i tried to track
down the problem. But as far as i can see the reordering of the
match results isn't done by ido-set-matches-1. The position of the
matches items in ido-cur-list and in the result of ido-set-matches-1
is the same. Think of 

(remove-if '(lambda (x) (not (member x after-match)) before-match)

So i assume that the Problem isn't at that place.

greetz didi

-- 
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

bug#5724: 23.1.94; ido bug in next match

[Leo]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On 2010-03-26 09:40 +0000, Christian Dietrich wrote:
> Hi,
> i can reproduce your bug here with emacs 23.1, and i tried to track
> down the problem. But as far as i can see the reordering of the
> match results isn't done by ido-set-matches-1. The position of the
> matches items in ido-cur-list and in the result of ido-set-matches-1
> is the same. Think of 
>
> (remove-if '(lambda (x) (not (member x after-match)) before-match)
>
> So i assume that the Problem isn't at that place.
>
> greetz didi

I think I have located the problem.

ido-set-matches is called with different args when C-s so it returns
different matches. I couldn't understand why it is designed this way. I
am surprised no one has been annoyed by this bug. It has caused me to
choose the wrong match quite often. I have attempted a fix by simply
rotating the ido-matches when rotating.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ido.diff --]
[-- Type: text/x-patch, Size: 2250 bytes --]

diff --git a/lisp/ido.el b/lisp/ido.el
index e414408..803fa74 100644
--- a/lisp/ido.el
+++ b/lisp/ido.el
@@ -3145,20 +3145,18 @@ If repeated, insert text from buffer instead."
 (defun ido-next-match ()
   "Put first element of `ido-matches' at the end of the list."
   (interactive)
-  (if ido-matches
-      (let ((next (cadr ido-matches)))
-	(setq ido-cur-list (ido-chop ido-cur-list next))
-	(setq ido-rescan t)
-	(setq ido-rotate t))))
+  (when ido-matches
+    (setq ido-matches
+          (ido-chop ido-matches (cadr ido-matches)))
+    (setq ido-rotate t)))
 
 (defun ido-prev-match ()
   "Put last element of `ido-matches' at the front of the list."
   (interactive)
-  (if ido-matches
-      (let ((prev (car (last ido-matches))))
-	(setq ido-cur-list (ido-chop ido-cur-list prev))
-	(setq ido-rescan t)
-	(setq ido-rotate t))))
+  (when ido-matches
+    (setq ido-matches
+          (ido-chop ido-matches (car (last ido-matches))))
+    (setq ido-rotate t)))
 
 (defun ido-next-match-dir ()
   "Find next directory in match list.
@@ -3177,7 +3175,8 @@ first matching file."
       (while (and (< i cnt) (not (ido-final-slash (nth i ido-matches))))
 	(setq i (1+ i)))
       (if (< i cnt)
-	  (setq ido-cur-list (ido-chop ido-cur-list (nth i ido-matches)))))))
+	  (setq ido-matches (ido-chop ido-matches (nth i ido-matches))
+                ido-rotate t)))))
 
 (defun ido-prev-match-dir ()
   "Find previous directory in match list.
@@ -3196,7 +3195,8 @@ for first matching file."
       (while (and (> i 0) (not (ido-final-slash (nth i ido-matches))))
 	(setq i (1- i)))
       (if (> i 0)
-	  (setq ido-cur-list (ido-chop ido-cur-list (nth i ido-matches)))))))
+	  (setq ido-matches (ido-chop ido-matches (nth i ido-matches))
+                ido-rotate t)))))
 
 (defun ido-restrict-to-matches ()
   "Set current item list to the currently matched items."
@@ -4494,8 +4494,10 @@ For details of keybindings, see `ido-find-file'."
 
 	;; Update the list of matches
 	(setq ido-text contents)
-	(ido-set-matches)
-	(ido-trace "new    " ido-matches)
+	(if ido-rotate
+            (setq ido-rotate nil)
+          (ido-set-matches)
+          (ido-trace "new    " ido-matches))
 
 	(when (and ido-enter-matching-directory
 		   ido-matches

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


Cheers,

Leo

bug#5724: 23.1.94; ido bug in next match

[Leo]

This bug seems to be fixed in:

http://repo.or.cz/w/emacs.git/commitdiff/7c481af3e2b7dc3a530c7e0d9c61b0721aadbd1d

"(ido-next-match, ido-prev-match): Fix stray reordering of matching
 items when cycling through the matches."

Leo


-- 
Oracle is the new evil