Re: Reverse incremental search provoking errors

[Chet Ramey]

On 3/31/14, 2:12 PM, Thomas Bolemann wrote:
>    In bash-4.3-beta2 a new feature has been introduced under
>    2. a.
>    Changed message when an incremental search fails to include "failed" in
>    the prompt and display the entire search string instead of just the
>    last
>    matching portion.
> 
>    But there's another side effect to this:
>    the string matching the characters typed first is returned, although
>    failed is printed.
>    I understand the good intent of this feature, but coming from bash 4.2,
>    I find it quite disturbing, as it's provoking errors if one doesn't
>    check, if reverse search has succeeded or failed (e.g. for a long
>    string) and just presses enter.
>    While this has not happened to me yet, I found the previous behaviour
>    very comfortable and safe. If no matching results are present I don't
>    think its a good idea to print 'failed' and just return the next best
>    match.

I think we're going to have to agree to disagree.  The bash-4.3 behavior
of printing the entire search string instead of just the matching portion,
leaving the user to guess about the undisplayed characters, and noting
that the search has failed is clearly better.

I'm not sure you realize that that's the only difference between bash-4.2
and bash-4.3.  Both versions stop at the line that matches the portion of
the search string before the first non-matching character.

What do you think bash-4.2 is doing?  Or maybe a better question is what is
your vendor-shipped version of bash-4.2 doing?

>    (Not very realistic) example search for "longcommand remember-the-milk"
>    and a typo:
>    "[Ctrl-r] remember-the-milk"  may return "rm somefiles". One has to
>    look carefully look if the search has failed otherwise, which many
>    people don't do, especially if they're using to the previous behaviour.

Both bash-4.2 and bash-4.3 leave `rm somefiles' as the current line in the
editing buffer and ring the bell on each subsequent non-matching character.

>    I didn't find a way to turn this feature of and get the old behaviour.
>    Is it possible to at least make it optional in the next release that
>    the next best match is returned?

That's the way incremental search has always behaved.  There is no `old
behavior'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/