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/