From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#14729: 24.3.50; Isearch oddity Date: Sun, 05 Dec 2021 11:35:51 +0200 Organization: LINKOV.NET Message-ID: <86bl1vbcqw.fsf@mail.linkov.net> References: <87mwqbay6p.fsf@mail.jurta.org> <87haggmv72.fsf@mail.jurta.org> <87h7bpqb6q.fsf@gnus.org> <865ys4taxv.fsf@mail.linkov.net> <87pmqcxbwn.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9037"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: 14729@debbugs.gnu.org, Dani Moncayo To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 05 11:05:49 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtoOz-000271-JF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Dec 2021 11:05:49 +0100 Original-Received: from localhost ([::1]:50228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtoOy-0003u4-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Dec 2021 05:05:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46134) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtoOM-0003cE-Ld for bug-gnu-emacs@gnu.org; Sun, 05 Dec 2021 05:05:10 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44877) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mtoOF-0002pf-IY for bug-gnu-emacs@gnu.org; Sun, 05 Dec 2021 05:05:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mtoOE-0004yE-Kn for bug-gnu-emacs@gnu.org; Sun, 05 Dec 2021 05:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Dec 2021 10:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14729 X-GNU-PR-Package: emacs Original-Received: via spool by 14729-submit@debbugs.gnu.org id=B14729.163869868719029 (code B ref 14729); Sun, 05 Dec 2021 10:05:02 +0000 Original-Received: (at 14729) by debbugs.gnu.org; 5 Dec 2021 10:04:47 +0000 Original-Received: from localhost ([127.0.0.1]:56417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtoNz-0004wq-60 for submit@debbugs.gnu.org; Sun, 05 Dec 2021 05:04:47 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:34139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtoNt-0004vR-KR for 14729@debbugs.gnu.org; Sun, 05 Dec 2021 05:04:41 -0500 Original-Received: (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 619FFE000C; Sun, 5 Dec 2021 10:04:35 +0000 (UTC) In-Reply-To: <87pmqcxbwn.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 04 Dec 2021 23:06:48 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221604 Archived-At: >> Or to turn the failing search into a successful one >> since the search string matches the buffer. > > But we've skipped past the final match, Actually, the final match is not skipped - point is still on the final match. That error is just an intermediate step before wrapping. > so I think it's correct to still say that we've skipped past, even if > we add more characters. Probably. When the users type more characters on the wrapping search, isn't this an indication that the users changed their mind and decided to continue searching for more text? >> OTOH, the current behavior also makes sense >> since it highlights the last failing characters >> typed by the user. E.g. compare it with `C-s bufzzz'. > > Hm... yes... but it does seem wrong (in one way or another) in the > original test case. Honestly, I have no idea what is right and what is wrong in this situation 🤐