First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Tobias Bading]

Hello everyone,

I'm using Emacs 22.1 compiled under MacOS X and Windoze XP from the  
EMACS_22_1 tag in the cvs repository for quite some time now and both  
of 'em work great, wouldn't want to live without them :-) . However,  
there's a minor bug that really bugs me. It is reproducible on both  
platforms without any customizations, i.e. my .emacs file moved out  
of the way. It goes like this:
Start a fresh emacs, then C-s 1 RET, C-s 2 RET, C-s 3 RET to search  
for "1", "2" and "3". The value of variable search-ring is ("3" "2"  
"1") now. So far, so good. Now, let's try to search for "1" again  
using M-p (isearch-ring-retreat) in isearch-mode. A C-s C-s searches  
for "3", now a M-p and you're searching for "2", but the next M-p  
does not search for "1", but for "3" again! And another M-p brings  
you to "2". This is what I noticed on both platforms: After the  
initial C-s C-s sequence, the minibuffer shows "I-search: 3", the  
cursor is still in your buffer and the tool bar as well as the menu  
bar remain unchanged. After the first M-p the minibuffer displays "I- 
search: 2" and the cursor is at the end of the minibuffer. However,  
the tool bar and the menu bar still remain unchanged. I guess this is  
part of the problem, because the second M-p finally adapts the tool  
bar and the menu bar to the fact that the cursor is in the minibuffer  
now, i.e. the Minibuf menu item appears and a few icons are grayed  
out. Unfortunately, the second M-p also jumps back to the first  
element of search-ring instead of showing the third element. So to  
reach the third element of search-ring, you have to press M-p four  
times instead of twice :-( . I hope I'm not the only one having this  
problem and that there's a fix available :-).

Kind regards,
Tobias

PS: The frame's title is incorrect after the first M-p as well,  
noticeable if you have a (setq frame-title-format "Emacs: %b") in  
your .emacs file.

PPS: isearch-forward-regexp has the same problem :-( .

First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Tobias Bading]

Hello everyone,

I'm using Emacs 22.1 compiled under MacOS X and Windoze XP from the  
EMACS_22_1 tag in the cvs repository for quite some time now and both  
of 'em work great, wouldn't want to live without them :-). However,  
there's a minor bug that really bugs me. It is reproducible on both  
platforms without any customizations, i.e. my .emacs file moved out  
of the way. It goes like this:
Start a fresh emacs, then C-s 1 RET, C-s 2 RET, C-s 3 RET to search  
for "1", "2" and "3". The value of variable search-ring is ("3" "2"  
"1") now. So far, so good. Now, let's try to search for "1" again  
using M-p (isearch-ring-retreat) in isearch-mode. A C-s C-s searches  
for "3", now a M-p and you're searching for "2", but the next M-p  
does not search for "1", but for "3" again! And another M-p brings  
you to "2". This is what I noticed on both platforms: After the  
initial C-s C-s sequence, the minibuffer shows "I-search: 3", the  
cursor is still in your buffer and the tool bar as well as the menu  
bar remain unchanged. After the first M-p the minibuffer displays "I- 
search: 2" and the cursor is at the end of the minibuffer. However,  
the tool bar and the menu bar still remain unchanged. I guess this is  
part of the problem, because the second M-p finally adapts the tool  
bar and the menu bar to the fact that the cursor is in the minibuffer  
now, i.e. the Minibuf menu item appears and a few icons are grayed  
out. Unfortunately, the second M-p also jumps back to the first  
element of search-ring instead of showing the third element. So to  
reach the third element of search-ring, you have to press M-p four  
times instead of twice :-(. I hope I'm not the only one having this  
problem and that there's a fix available :-).

Have a nice weekend,
Tobias

PS: The frame's title is incorrect after the first M-p as well,  
noticeable if you have a (setq frame-title-format "Emacs: %b") in  
your .emacs file.

PPS: isearch-forward-regexp has the same problem :-(.

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> I'm using Emacs 22.1 compiled under MacOS X and Windoze XP from the
> EMACS_22_1 tag in the cvs repository for quite some time now and both  of
> em work great, wouldn't want to live without them :-). However,  there's
> a minor bug that really bugs me. It is reproducible on both  platforms
> without any customizations, i.e. my .emacs file moved out  of the way. It
> goes like this:
> Start a fresh emacs, then C-s 1 RET, C-s 2 RET, C-s 3 RET to search for
> "1", "2" and "3". The value of variable search-ring is ("3" "2"  "1")
> now. So far, so good. Now, let's try to search for "1" again  using M-p
> (isearch-ring-retreat) in isearch-mode. A C-s C-s searches  for "3", now
> a M-p and you're searching for "2", but the next M-p  does not search for
> "1", but for "3" again! And another M-p brings  you to "2". This is what
> I noticed on both platforms: After the  initial C-s C-s sequence, the
> minibuffer shows "I-search: 3", the  cursor is still in your buffer and
> the tool bar as well as the menu  bar remain unchanged. After the first
> M-p the minibuffer displays "I-
> search: 2" and the cursor is at the end of the minibuffer. However, the
> tool bar and the menu bar still remain unchanged. I guess this is  part of
> the problem, because the second M-p finally adapts the tool  bar and the
> menu bar to the fact that the cursor is in the minibuffer  now, i.e. the
> Minibuf menu item appears and a few icons are grayed  out. Unfortunately,
> the second M-p also jumps back to the first  element of search-ring
> instead of showing the third element. So to  reach the third element of
> search-ring, you have to press M-p four  times instead of
> twice :-(. I hope I'm not the only one having this  problem and that
> there's a fix available :-).

Thank you for the bug report.  I hope it is possible to fix this
undesirable behavior by using the HISTPOS argument of read-from-minibuffer
where HISTPOS will point to the correct history position in the search
ring.  This also gives us the opportunity to rewrite isearch-edit-string
to remove unnecessary ad-hoc minibuffer precessing tricks that cause the
incorrect behavior you described in the second part of your bug report.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> Thank you for the bug report.  I hope it is possible to fix this
> undesirable behavior by using the HISTPOS argument of read-from-minibuffer
> where HISTPOS will point to the correct history position in the search
> ring.  This also gives us the opportunity to rewrite isearch-edit-string
> to remove unnecessary ad-hoc minibuffer precessing tricks that cause the
> incorrect behavior you described in the second part of your bug report.

Below is a patch that fixes all these problems.  It uses
search-ring-yank-pointer and regexp-search-ring-yank-pointer
for the HISTPOS argument of read-from-minibuffer that gives
the correct initial minibuffer search history position for
isearch-edit-string.

It also gets rid of all trickery used to read the first character
typed in the minibuffer (that removes another set of problems;
see related old bug reports).  It adds a new backward-compatible
command `isearch-edit-string-set-word' bound to C-w in the minibuffer
that calls `kill-region' when the mark is active, and otherwise does
word search after exiting `isearch-edit-string' (the mark is not active
when `isearch-edit-string' just created the minibuffer, and without
the mark `kill-region' would fail anyway).

This preserves the behavior described in the Emacs manual:

`C-s <RET> C-w WORDS <RET>'
     Search for WORDS, ignoring details of punctuation.

Index: lisp/isearch.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.313
diff -c -r1.313 isearch.el
*** lisp/isearch.el	28 Feb 2008 01:57:42 -0000	1.313
--- lisp/isearch.el	9 Mar 2008 21:57:02 -0000
***************
*** 436,441 ****
--- 436,442 ----
      (define-key map "\M-\t" 'isearch-complete-edit)
      (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
      (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
+     (define-key map "\C-w"  'isearch-edit-string-set-word)
      (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
      (define-key map [right] 'isearch-yank-char-in-minibuffer)
      map)
***************
*** 1025,1061 ****
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
- 	  (isearch-message) ;; for read-char
  	  (unwind-protect
! 	      (let* (;; Why does following read-char echo?
! 		     ;;(echo-keystrokes 0) ;; not needed with above message
! 		     (e (let ((cursor-in-echo-area t))
! 			  (read-event)))
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol)
! 		     (message-log-max nil))
! 		;; If the first character the user types when we prompt them
! 		;; for a string is the yank-word character, then go into
! 		;; word-search mode.  Otherwise unread that character and
! 		;; read a key the normal way.
! 		;; Word search does not apply (yet) to regexp searches,
! 		;; no check is made here.
! 		(message "%s" (isearch-message-prefix nil nil t))
! 		(if (memq (lookup-key isearch-mode-map (vector e))
! 			  '(isearch-yank-word
! 			    isearch-yank-word-or-char))
! 		    (setq isearch-word t;; so message-prefix is right
! 			  isearch-new-word t)
! 		  (cancel-kbd-macro-events)
! 		  (isearch-unread e))
! 		(setq cursor-in-echo-area nil)
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
                         isearch-string
                         minibuffer-local-isearch-map nil
!                        (if isearch-regexp 'regexp-search-ring 'search-ring)
                         nil t)
  		      isearch-new-message
  		      (mapconcat 'isearch-text-char-description
--- 1026,1046 ----
  	  ;; that can change their values.
  	  (setq old-point (point) old-other-end isearch-other-end)
  
  	  (unwind-protect
! 	      (let* ((message-log-max nil)
  		     ;; Binding minibuffer-history-symbol to nil is a work-around
  		     ;; for some incompatibility with gmhist.
! 		     (minibuffer-history-symbol))
  		(setq isearch-new-string
                        (read-from-minibuffer
                         (isearch-message-prefix nil nil isearch-nonincremental)
                         isearch-string
                         minibuffer-local-isearch-map nil
!                        (if isearch-regexp
! 			   (cons 'regexp-search-ring
! 				 (1+ (or regexp-search-ring-yank-pointer -1)))
! 			 (cons 'search-ring
! 			       (1+ (or search-ring-yank-pointer -1))))
                         nil t)
  		      isearch-new-message
  		      (mapconcat 'isearch-text-char-description
***************
*** 1116,1121 ****
--- 1101,1116 ----
       (isearch-abort)  ;; outside of let to restore outside global values
       )))
  
+ (defun isearch-edit-string-set-word ()
+   "Do word search after exiting `isearch-edit-string'.
+ If the mark is not active in the search string editing minibuffer,
+ then after exiting `isearch-edit-string', do word search.
+ Otherwise, kill text between point and mark in the minibuffer."
+   (interactive)
+   (if mark-active
+       (kill-region (point) (mark))
+     (setq isearch-word t isearch-new-word t)))
+ 
  (defun isearch-nonincremental-exit-minibuffer ()
    (interactive)
    (setq isearch-nonincremental t)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Stefan Monnier]

> Below is a patch that fixes all these problems.  It uses
> search-ring-yank-pointer and regexp-search-ring-yank-pointer
> for the HISTPOS argument of read-from-minibuffer that gives
> the correct initial minibuffer search history position for
> isearch-edit-string.

Thanks.

> It also gets rid of all trickery used to read the first character
> typed in the minibuffer (that removes another set of problems;
> see related old bug reports).  It adds a new backward-compatible
> command `isearch-edit-string-set-word' bound to C-w in the minibuffer
> that calls `kill-region' when the mark is active, and otherwise does
> word search after exiting `isearch-edit-string' (the mark is not active
> when `isearch-edit-string' just created the minibuffer, and without
> the mark `kill-region' would fail anyway).

> This preserves the behavior described in the Emacs manual:

> `C-s <RET> C-w WORDS <RET>'
>      Search for WORDS, ignoring details of punctuation.

This seems unrelated, right?
It looks like a good change.  But I wonder why we don't use an approach
similar to the M-r binding to isearch-toggle-regexp.  Of course, we'd
rather not eat yet-another key (e.g. bind M-w to isearch-toggle-word),
but maybe we could change isearch-toggle-regexp into
isearch-cycle-regexp-word, such that the command cycles between
plain/regexp/word searches.


        Stefan


> Index: lisp/isearch.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/isearch.el,v
> retrieving revision 1.313
> diff -c -r1.313 isearch.el
> *** lisp/isearch.el	28 Feb 2008 01:57:42 -0000	1.313
> --- lisp/isearch.el	9 Mar 2008 21:57:02 -0000
> ***************
> *** 436,441 ****
> --- 436,442 ----
>       (define-key map "\M-\t" 'isearch-complete-edit)
>       (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
>       (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
> +     (define-key map "\C-w"  'isearch-edit-string-set-word)
>       (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
>       (define-key map [right] 'isearch-yank-char-in-minibuffer)
>       map)
> ***************
> *** 1025,1061 ****
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
  
> - 	  (isearch-message) ;; for read-char
>   	  (unwind-protect
> ! 	      (let* (;; Why does following read-char echo?
> ! 		     ;;(echo-keystrokes 0) ;; not needed with above message
> ! 		     (e (let ((cursor-in-echo-area t))
> ! 			  (read-event)))
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol)
> ! 		     (message-log-max nil))
> ! 		;; If the first character the user types when we prompt them
> ! 		;; for a string is the yank-word character, then go into
> ! 		;; word-search mode.  Otherwise unread that character and
> ! 		;; read a key the normal way.
> ! 		;; Word search does not apply (yet) to regexp searches,
> ! 		;; no check is made here.
> ! 		(message "%s" (isearch-message-prefix nil nil t))
> ! 		(if (memq (lookup-key isearch-mode-map (vector e))
> ! 			  '(isearch-yank-word
> ! 			    isearch-yank-word-or-char))
> ! 		    (setq isearch-word t;; so message-prefix is right
> ! 			  isearch-new-word t)
> ! 		  (cancel-kbd-macro-events)
> ! 		  (isearch-unread e))
> ! 		(setq cursor-in-echo-area nil)
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch-nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp 'regexp-search-ring 'search-ring)
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> --- 1026,1046 ----
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
  
>   	  (unwind-protect
> ! 	      (let* ((message-log-max nil)
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol))
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch-nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp
> ! 			   (cons 'regexp-search-ring
> ! 				 (1+ (or regexp-search-ring-yank-pointer -1)))
> ! 			 (cons 'search-ring
> ! 			       (1+ (or search-ring-yank-pointer -1))))
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> ***************
> *** 1116,1121 ****
> --- 1101,1116 ----
>        (isearch-abort)  ;; outside of let to restore outside global values
>        )))
  
> + (defun isearch-edit-string-set-word ()
> +   "Do word search after exiting `isearch-edit-string'.
> + If the mark is not active in the search string editing minibuffer,
> + then after exiting `isearch-edit-string', do word search.
> + Otherwise, kill text between point and mark in the minibuffer."
> +   (interactive)
> +   (if mark-active
> +       (kill-region (point) (mark))
> +     (setq isearch-word t isearch-new-word t)))
> + 
>   (defun isearch-nonincremental-exit-minibuffer ()
>     (interactive)
>     (setq isearch-nonincremental t)

> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Tobias Bading]

Hi Juri,

thanks a million! I managed to "port" your fix down to the 1.297  
version (tagged EMACS_22_1) by only applying your patch of isearch- 
edit-string and it seems to work fine. Funnily enough the patch only  
works if I copy the whole definition of the patched isearch-edit- 
string into my .emacs file. If I put the patch into the original  
isearch.el under c:\emacs\lisp at work or /usr/local/share/emacs/22.1/ 
lisp on my Mac at home, the patch is ignored :-(. I *did* compile the  
file in both cases, the isearch.elc file was created without a  
warning or error. What's up with that? Is isearch.el dumped into my  
emacs binaries and emacs doesn't realize that the version on disk is  
newer or something?

Thanks again,
Tobias


On 09.03.2008, at 22:59, Juri Linkov wrote:

>> Thank you for the bug report.  I hope it is possible to fix this
>> undesirable behavior by using the HISTPOS argument of read-from- 
>> minibuffer
>> where HISTPOS will point to the correct history position in the  
>> search
>> ring.  This also gives us the opportunity to rewrite isearch-edit- 
>> string
>> to remove unnecessary ad-hoc minibuffer precessing tricks that  
>> cause the
>> incorrect behavior you described in the second part of your bug  
>> report.
>
> Below is a patch that fixes all these problems.  It uses
> search-ring-yank-pointer and regexp-search-ring-yank-pointer
> for the HISTPOS argument of read-from-minibuffer that gives
> the correct initial minibuffer search history position for
> isearch-edit-string.
>
> It also gets rid of all trickery used to read the first character
> typed in the minibuffer (that removes another set of problems;
> see related old bug reports).  It adds a new backward-compatible
> command `isearch-edit-string-set-word' bound to C-w in the minibuffer
> that calls `kill-region' when the mark is active, and otherwise does
> word search after exiting `isearch-edit-string' (the mark is not  
> active
> when `isearch-edit-string' just created the minibuffer, and without
> the mark `kill-region' would fail anyway).
>
> This preserves the behavior described in the Emacs manual:
>
> `C-s <RET> C-w WORDS <RET>'
>      Search for WORDS, ignoring details of punctuation.
>
> Index: lisp/isearch.el
> ===================================================================
> RCS file: /sources/emacs/emacs/lisp/isearch.el,v
> retrieving revision 1.313
> diff -c -r1.313 isearch.el
> *** lisp/isearch.el	28 Feb 2008 01:57:42 -0000	1.313
> --- lisp/isearch.el	9 Mar 2008 21:57:02 -0000
> ***************
> *** 436,441 ****
> --- 436,442 ----
>       (define-key map "\M-\t" 'isearch-complete-edit)
>       (define-key map "\C-s"  'isearch-forward-exit-minibuffer)
>       (define-key map "\C-r"  'isearch-reverse-exit-minibuffer)
> +     (define-key map "\C-w"  'isearch-edit-string-set-word)
>       (define-key map "\C-f"  'isearch-yank-char-in-minibuffer)
>       (define-key map [right] 'isearch-yank-char-in-minibuffer)
>       map)
> ***************
> *** 1025,1061 ****
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
>
> - 	  (isearch-message) ;; for read-char
>   	  (unwind-protect
> ! 	      (let* (;; Why does following read-char echo?
> ! 		     ;;(echo-keystrokes 0) ;; not needed with above message
> ! 		     (e (let ((cursor-in-echo-area t))
> ! 			  (read-event)))
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol)
> ! 		     (message-log-max nil))
> ! 		;; If the first character the user types when we prompt them
> ! 		;; for a string is the yank-word character, then go into
> ! 		;; word-search mode.  Otherwise unread that character and
> ! 		;; read a key the normal way.
> ! 		;; Word search does not apply (yet) to regexp searches,
> ! 		;; no check is made here.
> ! 		(message "%s" (isearch-message-prefix nil nil t))
> ! 		(if (memq (lookup-key isearch-mode-map (vector e))
> ! 			  '(isearch-yank-word
> ! 			    isearch-yank-word-or-char))
> ! 		    (setq isearch-word t;; so message-prefix is right
> ! 			  isearch-new-word t)
> ! 		  (cancel-kbd-macro-events)
> ! 		  (isearch-unread e))
> ! 		(setq cursor-in-echo-area nil)
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch- 
> nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp 'regexp-search-ring  
> 'search-ring)
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> --- 1026,1046 ----
>   	  ;; that can change their values.
>   	  (setq old-point (point) old-other-end isearch-other-end)
>
>   	  (unwind-protect
> ! 	      (let* ((message-log-max nil)
>   		     ;; Binding minibuffer-history-symbol to nil is a work-around
>   		     ;; for some incompatibility with gmhist.
> ! 		     (minibuffer-history-symbol))
>   		(setq isearch-new-string
>                         (read-from-minibuffer
>                          (isearch-message-prefix nil nil isearch- 
> nonincremental)
>                          isearch-string
>                          minibuffer-local-isearch-map nil
> !                        (if isearch-regexp
> ! 			   (cons 'regexp-search-ring
> ! 				 (1+ (or regexp-search-ring-yank-pointer -1)))
> ! 			 (cons 'search-ring
> ! 			       (1+ (or search-ring-yank-pointer -1))))
>                          nil t)
>   		      isearch-new-message
>   		      (mapconcat 'isearch-text-char-description
> ***************
> *** 1116,1121 ****
> --- 1101,1116 ----
>        (isearch-abort)  ;; outside of let to restore outside global  
> values
>        )))
>
> + (defun isearch-edit-string-set-word ()
> +   "Do word search after exiting `isearch-edit-string'.
> + If the mark is not active in the search string editing minibuffer,
> + then after exiting `isearch-edit-string', do word search.
> + Otherwise, kill text between point and mark in the minibuffer."
> +   (interactive)
> +   (if mark-active
> +       (kill-region (point) (mark))
> +     (setq isearch-word t isearch-new-word t)))
> +
>   (defun isearch-nonincremental-exit-minibuffer ()
>     (interactive)
>     (setq isearch-nonincremental t)
>
> -- 
> Juri Linkov
> http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> thanks a million! I managed to "port" your fix down to the 1.297 version
> (tagged EMACS_22_1) by only applying your patch of isearch- 
> edit-string and it seems to work fine. Funnily enough the patch only works
> if I copy the whole definition of the patched isearch-edit- 
> string into my .emacs file. If I put the patch into the original
> isearch.el under c:\emacs\lisp at work or /usr/local/share/emacs/22.1/
> lisp on my Mac at home, the patch is ignored :-(. I *did* compile the
> file in both cases, the isearch.elc file was created without a  warning or
> error. What's up with that? Is isearch.el dumped into my  emacs binaries
> and emacs doesn't realize that the version on disk is  newer or something?

Yes, your guess is right: isearch.el is dumped into the Emacs executable,
but you can reload the newest version of isearch.el in your .emacs with
(load "isearch").

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: First two elements of search-ring shown twice in minibuffer when using M-p multiple times?

[Juri Linkov]

> Below is a patch that fixes all these problems.  It uses
> search-ring-yank-pointer and regexp-search-ring-yank-pointer
> for the HISTPOS argument of read-from-minibuffer that gives
> the correct initial minibuffer search history position for
> isearch-edit-string.

I noticed that this change also fixed `C-s M-n M-n ...' to work correctly,
i.e. to start with the last element of the search ring and advance down
to the first element of the search ring in the minibuffer.

But I see one inconvenience in using M-p.  It is intended to retrieve
the previous search string from the search ring.  So when the ring is
'("3" "2" "1"), `C-s M-p' could retrieve "3".  I suppose it currently
retrieves "2" because there exists another convenient key sequence
`C-s C-s' to retrieve the last search string "3"?

However, when the current search string is not the same as the last
search string in the search ring, it seems more natural to expect M-p
to retrieve the last search string "3", i.e. what `C-s 4 M-p'
should retrieve: "3" or "2", I'm not sure.

-- 
Juri Linkov
http://www.jurta.org/emacs/