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

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

[Dani Moncayo]

Hi,

Try this from "emacs -Q":
1. Type "C-x C-f".
2. Type "C-s" (or "C-r").

In step #2, the minibuffer prompt changes from "Find file" to
"I-search", but the buffer's default directory is not cleared.
Instead, it becomes read-only like the prompt text, so that I have to
type the Isearch input after it.

This is quite confusing.  The minibuffer should be cleared, like "M-s"
and "M-r" commands do.


In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601)
 of 2011-10-27 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.5)'

-- 
Dani Moncayo

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

[Juri Linkov]

> Try this from "emacs -Q":
> 1. Type "C-x C-f".
> 2. Type "C-s" (or "C-r").
>
> In step #2, the minibuffer prompt changes from "Find file" to
> "I-search", but the buffer's default directory is not cleared.
> Instead, it becomes read-only like the prompt text, so that I have to
> type the Isearch input after it.
>
> This is quite confusing.  The minibuffer should be cleared, like "M-s"
> and "M-r" commands do.

??? This is the essential behavior of Isearch, so you can search in
existing text.

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

[Dani Moncayo]

> ??? This is the essential behavior of Isearch, so you can search in
> existing text.

??? I don't understand you, and I guess you've not understood me.

Please, try the recipe, and compare the behavior of C-s inside the
minibuffer wrt the behavior of M-s.

Isearch should be activated always with a clear prompt "I-search: ",
not with garbage "I-search: blablabla".


-- 
Dani Moncayo

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

[Juri Linkov]

> Isearch should be activated always with a clear prompt "I-search: ",
> not with garbage "I-search: blablabla".

It seems you are confused that blablabla is not garbage,
but text that you can search, i.e. try to type `C-r bla'.

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

[Dani Moncayo]

Severity: wishlist
stop

>> Isearch should be activated always with a clear prompt "I-search: ",
>> not with garbage "I-search: blablabla".
>
> It seems you are confused that blablabla is not garbage,
> but text that you can search, i.e. try to type `C-r bla'.

Ok, I thought that "C-s", when invoked from the minibuffer, was
intended to search _only_ through the minibuffer history (like
"M-s"/"M-r" do), not also in the current minibuffer text.  I should
have read info node "(emacs)Isearch Minibuffer" before submitting this
bug report, sorry.

Now that I understand it, I'd like this bug report to become a feature request:

IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in
the current minibuffer text, because it is usually small enough not to
need that (how often do you use that feature?).

I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r:
* Focus exclusively in the minibuffer history.
* Have a minibuffer-specific prompt ("Next/Previous element matching
[regexp]: ") so that it is clear what's going on.
* Obviously, clear the minibuffer's previous input.

-- 
Dani Moncayo

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

[Dani Moncayo]

> I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r:
> * Focus exclusively in the minibuffer history.
> * Have a minibuffer-specific prompt ("Next/Previous element matching
> [regexp]: ") so that it is clear what's going on.
> * Obviously, clear the minibuffer's previous input.
                                      ^^^^^^^^
I meant "current input", sorry. I.e. show the new prompt followed by
nothing but the cursor.

-- 
Dani Moncayo

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

[Juri Linkov]

> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in
> the current minibuffer text, because it is usually small enough not to
> need that (how often do you use that feature?).

I use this feature all the time!

> I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r:
> * Focus exclusively in the minibuffer history.
> * Have a minibuffer-specific prompt ("Next/Previous element matching
> [regexp]: ") so that it is clear what's going on.
> * Obviously, clear the minibuffer's current input.

If you like M-s and M-r, then just use them.  They are like non-incremental
versions `M-x search-forward RET' and `M-x search-backward RET'.

But C-s should work like Isearch, and not clear text before it starts to
search in it.

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

[Dani Moncayo]

On Sun, Nov 6, 2011 at 17:16, Juri Linkov <juri@jurta.org> wrote:
>> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in
>> the current minibuffer text, because it is usually small enough not to
>> need that (how often do you use that feature?).
>
> I use this feature all the time!

For searching in the _current_ minibuffer text?  How long are such text?

>> I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r:
>> * Focus exclusively in the minibuffer history.
>> * Have a minibuffer-specific prompt ("Next/Previous element matching
>> [regexp]: ") so that it is clear what's going on.
>> * Obviously, clear the minibuffer's current input.
>
> If you like M-s and M-r, then just use them.  They are like non-incremental
> versions `M-x search-forward RET' and `M-x search-backward RET'.

I can use them, of course, but as you've said, they are not
incremental.  Precisely, as I pointed out, I'd like to adjust C-M-s to
be the incremental version of M-s.

> But C-s should work like Isearch, and not clear text before it starts to
> search in it.

Well, think of the advantages and drawbacks.  IMHO, my proposal would
make the Isearch commands (in the minibuffer):
* More useful: what you want is to go straight to the history.
* Clearer: The prompt states clearly that you are searching the in
history, and nowhere else.
* Consistent with M-s and M-r.

-- 
Dani Moncayo

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

[Juri Linkov]

>>> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in
>>> the current minibuffer text, because it is usually small enough not to
>>> need that (how often do you use that feature?).
>>
>> I use this feature all the time!
>
> For searching in the _current_ minibuffer text?  How long are such text?

It doesn't matter how long it is.

Just imagine the minibuffer search as continuously searching backward
in a buffer with lines:

history3
history2
history1
history0

where "history0" is initial text in the minibuffer.

What you propose is to delete the line "history0" before running Isearch.
This makes no sense at all.

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

[Drew Adams]

> >> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) 
> >> look up also in the current minibuffer text, because
> >> it is usually small enough not to need that (how often
> >> do you use that feature?).
> >
> > I use this feature all the time!
> 
> For searching in the _current_ minibuffer text?  How long are 
> such text?

1. Yes, for searching the _current_ minibuffer text.  That's what C-s/C-r are
for: searching the current buffer.

2. And yes, minibuffer text can be large - as large as you like.

The fact that it often is not large with vanilla emacs (-Q) means only that
vanilla Emacs does not offer what is needed to really take advantage of large
input.  It even still binds `SPC' and `?' to completion (except for file names)
and help!

Vanilla Emacs unnecessarily puts obstacles in the way of editing large portions
of text in the minibuffer.  That will change (slowly) with time, I have
confidence.  It took decades to get Emacs Dev to finally allow `SPC' to be
self-inserting for file-name input.

3. And if you retrieve a previous minibuffer input, or if you cycle current
candidates into the minibuffer, and you want to edit that input, then yes,
Isearch (even regexp Isearch) can be very useful.

And the larger the previous input or current candidate, the more useful Isearch
becomes.

FWIW, in Icicles it is not unusual to have large, multi-line candidates in the
minibuffer.  This includes region text, function definitions, search contexts -
what have you.

4. The minibuffer is an _editing_ buffer, among other things.  General editing
commands, including Isearch, should be available there.

5. If you want a history-search command, then use M-s/M-r.  If those do not do
what you want, then propose additional *history*-search commands and
corresponding keys.  But please do not propose to change what C-s/C-r do.  What
they do is useful, and they are the standard keys for what they do.

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

[Dani Moncayo]

>>>> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in
>>>> the current minibuffer text, because it is usually small enough not to
>>>> need that (how often do you use that feature?).
>>>
>>> I use this feature all the time!
>>
>> For searching in the _current_ minibuffer text?  How long are such text?
>
> It doesn't matter how long it is.
>
> Just imagine the minibuffer search as continuously searching backward
> in a buffer with lines:
>
> history3
> history2
> history1
> history0
>
> where "history0" is initial text in the minibuffer.
>
> What you propose is to delete the line "history0" before running Isearch.
> This makes no sense at all.

Like you (and Drew, and I guess everyone in this list), I like
consistency and generality.

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!).  That scenario is not like users are
used to when the type `C-s'.  They expect to see a clean minibuffer
prompt "I-search: ", with the cursor after it.

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?



-- 
Dani Moncayo

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

[Dani Moncayo]

> Like you (and Drew, and I guess everyone in this list), I like
> consistency and generality.
>
> 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!).  That scenario is not like users are
> used to when the type `C-s'.  They expect to see a clean minibuffer
> prompt "I-search: ", with the cursor after it.
>
> 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?

Forget about this.  I now realize what you and Drew meant, and I agree with you.

I'm closing this bug report, and sorry for wasting your time.

-- 
Dani Moncayo

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

[Drew Adams]

> 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.

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

[Drew Adams]

> Forget about this.  I now realize what you and Drew meant, 
> and I agree with you.
> 
> I'm closing this bug report, and sorry for wasting your time.

Don't be sorry.  I agree that it might not be obvious to users what is going on
here, because of the fact that the minibuffer is doing double duty in this case.
The Isearch dialog takes place in the minibuffer, AND in this case it is the
minibuffer text that is being searched.  That can be confusing.

We should perhaps think of a (simple) way to make it more clear to users what's
going on.

With library mb-depth.el, when there is a recursive minibuffer we make that
clear by prepending a recursion-level indicator (e.g. highlighted `[2]').
Perhaps something similar could be done to help indicate what's going on with
Isearch in the minibuffer?

With this clarification about the problem, perhaps this bug should be turned
into a wishlist item rather than closed?

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

[Juri Linkov]

> Forget about this.  I now realize what you and Drew meant,
> and I agree with you.
>
> I'm closing this bug report, and sorry for wasting your time.

If you have not already seen it, I suggest you try to use C-r in the
Bash shell.  It works exactly like Isearch in the minibuffer in Emacs.

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

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> If you have not already seen it, I suggest you try to use C-r in the
> Bash shell.  It works exactly like Isearch in the minibuffer in Emacs.

There's one difference in detail though: in readline the text to search
is always displayed inside the prompt.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Dani Moncayo]

BTW, if the minibuffer and the echo area were each in its own window,
Isearch could work in the minibuffer *exactly* like it does in any
other buffer, i.e.:
* Using the echo area to show the Isearch prompt and current search string.
* Using the (mini)buffer to show (and navigate through) the matches,
without altering its current prompt.

Therefore, the fact that the minibuffer and the echo area share the
same window is unfortunate in this case.

-- 
Dani Moncayo

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

[Juri Linkov]

> BTW, if the minibuffer and the echo area were each in its own window,
> Isearch could work in the minibuffer *exactly* like it does in any
> other buffer, i.e.:
> * Using the echo area to show the Isearch prompt and current search string.
> * Using the (mini)buffer to show (and navigate through) the matches,
> without altering its current prompt.
>
> Therefore, the fact that the minibuffer and the echo area share the
> same window is unfortunate in this case.

Exactly.  There were several discussions about related problems for other
similar cases, such as http://thread.gmane.org/gmane.emacs.devel/107802