GNU bug report logs - #22118
23.2; Hitting ^W in a search selects the wrong word.

Previous Next

Full log

Message #34 received at 22118 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Jan-Mark <jms <at> codersco.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 22118 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#22118: 23.2; Hitting ^W in a search selects the wrong word.
Date: Sat, 29 Aug 2020 09:48:57 -0700

[Message part 1 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> writes:

>> Is the below patch still relevant?
>
> I don't know.  My patch tried to make the behavior in case of error
> slightly more useful, but now I see nothing useful in it because
> after a failure it makes no sense to type C-w C-w C-w ...
>
> I don't recommend making code in isearch.el more complicated to handle
> useless cases.  So I won't complain if you'll close this report.  :-)

Jan-Mark <jms <at> codersco.com> writes:

>> OK, thanks.  Any objections to closing this?
> I don't remember even what this was about. But ^W should not add words at the cursor if the
> search failed to match. Which is different from the search failing because it is at the last
> match (about to warp to the first match again).
>
> If the word 'aapX' is not in my text, 'aap noot' is, and I search for 'aapX' it brings me to
> 'aap noot' with a failure notice. If I than type ^W it should not start looking for 'aapX noot'.
> Just take the ^W out of the game in cases like this. I mean if 'aapX' cannot be found (even
> once) why should you allow people to look for 'aapX noot'?
>
> I still feel it is a bug, but I agree that it will not hit many people often. I have this once
> every 1000 hours (estimate). So it's not a big bug. But a bug nonetheless.
>
> If there is bigger bugs to fry, close it, if it is an easy fix (should be?) I'd say fix it first.

Thanks.

Juri feels that we should close this bug as a wontfix because it is not
worth complicating the isearch code over this.

Testing this again, I'm leaning more towards fixing the bug.  I think
there is definitely a bug here (the recipe in OP is still reproducible
on master), but it is very minor.  We also already have a proposed fix.

I considered also the use case when you have 'isearch-wrapped' set to a
non-nil value, which would make yank after last occurrence more useful.
I do remember having seen stuff similar to this in the past.
(Unfortunately I no longer use isearch and can't remember the exact
details, or if it was this exact bug.)

I therefore propose to push the proposed changes to master.  The
complexity is localized to only one function, which is already in itself
not too complicated.  I've attached a patch with proper ChangeLog for
review.

Juri, if you are still not convinced, we can go ahead and close this as
wontfix.  I'm okay with either option.

Best regards,
Stefan Kangas

[0001-Fix-isearch-yank-on-last-occurrence-of-search-string.patch (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.