From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56815: 29.0.50; Isearch lazy-highlight highlights too much when truncate-lines is in effect Date: Fri, 29 Jul 2022 22:31:22 +0300 Message-ID: <83a68r7m2d.fsf@gnu.org> References: <83mtct87ti.fsf@gnu.org> <865yjhc85k.fsf@mail.linkov.net> <83fsik8o39.fsf@gnu.org> <87r124kul6.fsf@gnus.org> <86mtcrpyzs.fsf@mail.linkov.net> <83bkt77nf9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27780"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56815@debbugs.gnu.org, juri@linkov.net To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 29 21:33:25 2022 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 1oHVjg-00070h-UX for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Jul 2022 21:33:25 +0200 Original-Received: from localhost ([::1]:56720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHVje-0005w7-Nk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Jul 2022 15:33:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHViN-0005sf-Dm for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 15:32:27 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43737) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHViM-0007f0-80 for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 15:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHViM-0007xg-2p for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 15:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jul 2022 19:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56815 X-GNU-PR-Package: emacs Original-Received: via spool by 56815-submit@debbugs.gnu.org id=B56815.165912308330553 (code B ref 56815); Fri, 29 Jul 2022 19:32:02 +0000 Original-Received: (at 56815) by debbugs.gnu.org; 29 Jul 2022 19:31:23 +0000 Original-Received: from localhost ([127.0.0.1]:33484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHVhj-0007wj-8J for submit@debbugs.gnu.org; Fri, 29 Jul 2022 15:31:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHVhi-0007wV-A2 for 56815@debbugs.gnu.org; Fri, 29 Jul 2022 15:31:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46332) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHVhW-0007Vl-PH; Fri, 29 Jul 2022 15:31:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZBKxyOj3P0PJKiClSt/j7Yu5qjk26WyXOMIZX30uV1c=; b=AVIUQA8w0k7Q Z+5q2nBiYLHy29MyEX+t3Cm4V4yDRd+V4KwhDq3kRyfjV/B9rwY0/ytrqSKz7VHpWyReQD/QgK7Lx eh3ujm7kagDZGwbjktpXKg9ihh9I12fkVg7G4xZFH1QKMF2xdHwIgyV+YQkv6TTYgM1LH9UYWInPv fz6xmQc7qd9J7to5ig/BvdhalftOcgnb/uk4ZnLlVYUds9eMfI31zfu7+7ZzUj0HqlfeYD8ccXbJE +RTr539OJ2QDVSugxwEKsD1QW5OBNSShW1FhQoGBQefMsLGmvMY2bsTslJ1SBE4JDlv3z1HtXGnqn U/kNEPHbKasUQrrrxqGaIQ==; Original-Received: from [87.69.77.57] (port=2765 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHVhW-0007MB-8I; Fri, 29 Jul 2022 15:31:10 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 29 Jul 2022 19:11:10 +0000) 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:238215 Archived-At: > Date: Fri, 29 Jul 2022 19:11:10 +0000 > From: Gregory Heytings > cc: juri@linkov.net, larsi@gnus.org, 56815@debbugs.gnu.org > > > I think posn-at-point is much faster, > > > > No, it is slower. On my laptop, with long-line.xml and truncate-lines: > > (benchmark-run 1000 (pos-visible-in-window-p 310000)) takes 4 seconds > > (benchmark-run 1000 (numberp (cadr (posn-at-point 310000)))) takes 6 seconds Why does it matter how long pos-visible-in-window-p takes when it cannot tell whether the position is visible? As for posn-at-point, 6 msec per position is not bad, if we in addition limit the number of matches by some reasonable number, like 100, say. Moreover, isearch.el could use some special-purpose algorithm for looking for visible matches in this case. For example, as soon as posn-at-point tells us a match is to the right of the window's right edge, isearch.el could go to the beginning of the next line and continue from there, instead of checking all the subsequent matches on the same line (with a result that is known in advance). This way, we will probably have even fewer matches, and the search will be faster, except for very large values of hscroll.