bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Kangas
Subject: bug#22118: 23.2; Hitting ^W in a search selects the wrong word.
Date: Sat, 29 Aug 2020 09:48:57 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Juri Linkov <juri@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@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

Attachment: 0001-Fix-isearch-yank-on-last-occurrence-of-search-string.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]