bug#22118: 23.2; Hitting ^W in a search selects the wrong word.

[Alan Mackenzie <acm@muc.de>]

Hello, Jan-Mark.

On Thu, Dec 10, 2015 at 11:01:39AM +0100, Jan-Mark wrote:
> Hi Alan,

> Thanks for your swift response and all the work you do on my favorite
> editor. People like you improve my life.

Thanks, that's appreciated.  Just one small request: when you reply,
would you please leave the Cc: to the bug archive.  That way, there's a
full record of the bug on the public list.

> >> Note that if you are not in 'last-occurrence' state, there is no
> >> problem, even at the last line. This bug only manifests itself if ^S has
> >> been hit until it shows "Failing the I-search" in the minibuffer.

> > Why is this behaviour a bug?  I think that the effect of ^W in
> > "last-occurrence" state is probably undefined in the manual.  Adding
> > "_aap" to the search string for each ^W does give the user feedback that
> > the ^W has actually been received and processed.

> Depending on how you define "bug". :-) Adding "_aap" is definitely what
> you would expect.

> There are three problems IMHO that make this a "bug":

> 1) The screen is inconsistent. The minibuffer shows a "aap_noot_aap" but
> the text buffer window's highlighting is not updated, only "aap_noot" is
> highlighted.

Don't forget, that by this stage the text in the minibuffer indicates
"not found".  So the main window highlights as much text as was found,
the minibuffer indicates the current search string, and any lazy
highlighting shows where the current search string would be found
earlier on.

All of this _is_ in the manual, on page "Errors in Incremental Search".

> 2) Hitting ^W again will add an other "_aap" (consistent with the end of
> the highlighting) which is unexpected to say the least. The minibuffer
> will contain "aap_noot_aap_aap" which is nowhere in the text.

This is true: the minibuffer shows what you are searching for.  This
indeed is nowhere in the text, but it's what you're searching for.

> 3) Not hitting ^W again, but ^S will wrap the search around looking for
> what is stated in the minibuffer ("aap_noot_aap") not what is
> highlighted in the text buffer window ("aap_noot"). The highlighting
> however is correct again ("aap_noot_aap").

The search is ALWAYS for what's in the minibuffer.  Once you hit ^S
again, the search becomes wrapped, and is no longer failing: it finds
"aap_noot_aap".

> > What do you think should happen in these circumstances?  Does the current
> > behaviour actually give you problems?

> Depending on how you define "problems". :-P However, there are two
> different ways emacs could deal with this that would definitely improve
> the ease of understanding and ease of use.

> a) The most consistent behavior, IMHO, would be to update the
> highlighting in the text buffer window. This way the the text buffer and
> mini buffer will be consistent. This way I don't have to check both to
> find out what is going on.

But when the search has failed, they should be different: in the main
window, you can sea the bit that matched, and in the minibuffer, in
bright red, you can see the bit that didn't match.  I think you're
asking for the distinction between successful and failing searches to be
removed.  This would surely be a Bad Thing.

> b) What would help me (personally) more would be if emacs would go back
> into search mode, highlight the whole search text in the text buffer
> window and remove the "Failing I-search:" from the mini buffer. The
> rational behind this is that changing the search string kind of "resets"
> the search status to the "default".

Internally, Isearch does indeed do this: it searches for the complete
string from the starting point each time you type a new character.  But
if it has already failed, it's going to stay failed unless something
like a C-s make the search wrap.

> I understand that if an I-search has failed extending the search string
> would keep you in the same search state (I.e., the last match.) However,
> by that reasoning hitting ^S should also not change the state. So I vote
> for behavior b) but I could live with behavior a).

> However I strongly feel, the mini buffer and the text buffer should be
> consistent.

They are the same as long as a search hasn't yet failed.  If it has, the
minibuffer shows what you're searching for, the text buffer what you
have found.

> If I type ^S until I find the last entry, hitting ^W appends
> "_aap" and updates the text buffer window. If I type ^S until I find the
> last entry, hit ^S again (going into Failing I-search) hitting ^W also
> appends "_aap" but does not update the text buffer window.

With the best will in the world, I honestly don't think there's a bug
here.  Could I ask you to have another look at that manual page ("Errors
in Incremental Search" in the Emacs manual) and carefully compare what
you read there with what you see on the screen.

By the way, Emacs 23.2 is now pretty old.  You might want to consider
upgrading to a newer version.  The current released version is 24.5.

> Regards,

> Jan-Mark

-- 
Alan Mackenzie (Nuremberg, Germany).