bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text

["Drew Adams" <drew.adams@oracle.com>]

> Actually, what I don't like in the current behavior of C-s (and the
> other 3) when invoked from the minibuffer is the fact that the current
> minibuffer text remains there after hitting C-s (like if I were typed
> it, but even being read-only!).

Dunno what you mean about the text being read-only.

The reason the minibuffer text remains there is that it is the text to be
searched.  It is not there as the current search string (or search "entry" as
you have referred to it).  It is there as the text to be searched.

Think of the minibuffer as an ordinary buffer with some text in it.  The text
that is in the minibuffer is text that you typed.  Or it is text that you
retrieved from a history cycle or search.  Or it is text that you retrieved by
cycling among the current completion candidates.

However the current minibuffer text got there, it is the text that gets searched
by C-s/C-r/C-M-s/C-M-r.

> That scenario is not like users are used to when the
> type `C-s'.

Yes it is.  The text you see is _not_ the search string.
It is the text to be searched.

> They expect to see a clean minibuffer
> prompt "I-search: ", with the cursor after it.

I agree that things can be a bit confusing because the minibuffer is used for
both the Isearch prompt and as the buffer to be searched.

Perhaps you or Juri has a suggestion how to make this clearer.  But your idea of
emptying the minibuffer doesn't fly because it is precisely the minibuffer text
that is to be searched.

> So, what about making the Isearch commands start that way, but
> considering the current minibuffer text (the one present before C-s
> was invoked) as the first entry for the search, as you pointed out?

The minibuffer content (text) is not an Isearch "entry".  It is the text to be
searched.