From: Stefan Kangas <stefan@marxist.se>
To: Jan-Mark <jms@codersco.com>
Cc: Alan Mackenzie <acm@muc.de>,
22118@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#22118: 23.2; Hitting ^W in a search selects the wrong word.
Date: Sat, 29 Aug 2020 09:48:57 -0700 [thread overview]
Message-ID: <CADwFkmkLL-vQ=Y=V+hNco_iBaiCr1LhWeUmW-wV7KasRtCq01Q@mail.gmail.com> (raw)
In-Reply-To: <a8ffbf34-77c3-f3bf-d5ab-df97cfaf9c9b@codersco.com> (Jan-Mark's message of "Thu, 13 Aug 2020 18:53:33 +0200")
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
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 #2: 0001-Fix-isearch-yank-on-last-occurrence-of-search-string.patch --]
[-- Type: text/x-diff, Size: 1578 bytes --]
From c5ebd3ee6c2c14727d926aef5d8e36682a00bb59 Mon Sep 17 00:00:00 2001
From: Juri Linkov <juri@linkov.net>
Date: Sat, 29 Aug 2020 18:33:05 +0200
Subject: [PATCH] Fix isearch yank on last occurrence of search string
* lisp/isearch.el (isearch-yank-internal):
(isearch-yank-prev-point): Fix yanking when we are at the last
occurrence of a search string. (Bug#22118)
---
lisp/isearch.el | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 81e83d7950..ac8b48e43a 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2518,6 +2518,8 @@ isearch-xterm-paste
(let ((pasted-text (nth 1 event)))
(isearch-yank-string pasted-text))))
+(defvar isearch-yank-prev-point nil)
+
(defun isearch-yank-internal (jumpform)
"Pull the text from point to the point reached by JUMPFORM.
JUMPFORM is a lambda expression that takes no arguments and returns
@@ -2528,7 +2530,14 @@ isearch-yank-internal
(save-excursion
(and (not isearch-forward) isearch-other-end
(goto-char isearch-other-end))
- (buffer-substring-no-properties (point) (funcall jumpform)))))
+ (and (not isearch-success) isearch-yank-prev-point
+ (goto-char isearch-yank-prev-point))
+ (buffer-substring-no-properties
+ (point)
+ (prog1
+ (setq isearch-yank-prev-point (funcall jumpform))
+ (when isearch-success
+ (setq isearch-yank-prev-point nil)))))))
(defun isearch-yank-char-in-minibuffer (&optional arg)
"Pull next character from buffer into end of search string in minibuffer."
--
2.28.0
next prev parent reply other threads:[~2020-08-29 16:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-08 17:54 bug#22118: 23.2; Hitting ^W in a search selects the wrong word jms
[not found] ` <mailman.1705.1449600970.31583.bug-gnu-emacs@gnu.org>
2015-12-10 9:25 ` Alan Mackenzie
[not found] ` <56694D83.3080902@codersco.com>
2015-12-10 12:10 ` Alan Mackenzie
2015-12-10 13:07 ` Jan-Mark
2015-12-11 22:54 ` Juri Linkov
2020-08-12 3:33 ` Stefan Kangas
2020-08-12 23:58 ` Juri Linkov
2020-08-13 1:22 ` Stefan Kangas
2020-08-13 16:53 ` Jan-Mark
2020-08-29 16:48 ` Stefan Kangas [this message]
2020-10-11 3:05 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADwFkmkLL-vQ=Y=V+hNco_iBaiCr1LhWeUmW-wV7KasRtCq01Q@mail.gmail.com' \
--to=stefan@marxist.se \
--cc=22118@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=jms@codersco.com \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).