bug#9185: 24.0.50; "C-s M-p" does not bring the tip of the search ring

[Dani Moncayo <dmoncayo@gmail.com>]

>> [*] FWIW: This is indeed the current behavior (use the last entry if
>> the minibuffer is empty), but I don't find it very suitable.  If the
>> user wanted to use the last entry, s?he would have typed M-p.
>> Therefore, IMO TRT here would be to return to Isearch with an empty
>> string.
>
> I suppose the last entry is used because otherwise an empty search
> string makes no sense.

It makes sense, I think: by "to set an empty search string" I mean to
return to the same state that had at the very beginning the Isearch
session, i.e., as if the user had deleted the current search string by
typing <DEL> repeatedly.

> I have nothing against this functionality
> because I never exit from the M-e minibuffer with empty input.

Neither me.  So this is not a very important issue (at least to us),
and we can leave it for now.  But I believe that setting an empty
search string would be TRT in that case.

>> Another failing use-case:
>> 0. C-s a <RET> C-s b <RET> C-s c <RET> C-s d <RET>
>> 1. C-s C-s        --> "d" is selected (ok).
>> 2. M-p M-p <RET>  --> "b" is selected (ok).
>> 3. M-p            --> "a" should have been selected, but I see that
>> "b" remains selected instead.
>
> We can't reliably count the number of typed M-p in `read-from-minibuffer'
> in `isearch-edit-string' to adjust the index accordingly and to add the
> same number of typed M-p to the index.  There is no reliable way to do this:

As you know, I still lack the knowledge of Elisp to help you in
implementation details, so I can say very little about this.  But I
think I should be possible to implement, since the intended behavior
is well defined and relatively simple:
* At the beggining of the Isearch session, the index would start at
the top of the ring (as does now).
* During the Isearch session, each typed M-p/M-n should use the index
to retrieve the suitable entry, and then should update the index,
regardless of whether we are in the minibuffer or outside it.

IMO, this is the behaviour most users would expect.  But if you find
it difficult to implement, you can adopt (by now) the alternative
behavior you've pointed out:

> Since `read-from-minibuffer' can't return the exact number of typed `M-p'
> then I think that M-p after `M-e M-p M-p <RET>' should start from the
> top of of the search ring, so `C-s C-s M-p M-p RET M-p' should select "d".
> This will provide a predictable result.

Since this is a different issue than the original one of this bug
report, I could file a separate bug asking for the wanted behavior.
WDYT?

-- 
Dani Moncayo