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#48581: 27.2; Default value of lazy-highlight-buffer-max-at-a-time is too low Date: Sat, 22 May 2021 14:08:11 +0300 Message-ID: <838s47kov8.fsf@gnu.org> References: <87k0nr9l2f.fsf@gmail.com> <83eedzksqj.fsf@gnu.org> <87eedzujpv.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39093"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48581@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 22 13:09:17 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 1lkPVM-0009vv-Az for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 13:09:16 +0200 Original-Received: from localhost ([::1]:51144 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkPVK-0003hq-Jf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 07:09:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkPV8-0003hQ-Uv for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55060) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkPV8-00045u-1B for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lkPV7-0001AJ-S4 for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 May 2021 11:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48581 X-GNU-PR-Package: emacs Original-Received: via spool by 48581-submit@debbugs.gnu.org id=B48581.16216817004431 (code B ref 48581); Sat, 22 May 2021 11:09:01 +0000 Original-Received: (at 48581) by debbugs.gnu.org; 22 May 2021 11:08:20 +0000 Original-Received: from localhost ([127.0.0.1]:38373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkPUS-00019P-96 for submit@debbugs.gnu.org; Sat, 22 May 2021 07:08:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkPUQ-00019B-00 for 48581@debbugs.gnu.org; Sat, 22 May 2021 07:08:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57206) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkPUK-0003rn-S2; Sat, 22 May 2021 07:08:12 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1646 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 1lkPUK-0003uJ-AO; Sat, 22 May 2021 07:08:12 -0400 In-Reply-To: <87eedzujpv.fsf@gmail.com> (message from Augusto Stoffel on Sat, 22 May 2021 12:49:16 +0200) 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:207027 Archived-At: > From: Augusto Stoffel > Cc: 48581@debbugs.gnu.org > Date: Sat, 22 May 2021 12:49:16 +0200 > > > You assume that (a) the main purpose of Isearch is to count the > > matches, > > No, the main purpose of Isearch is to search for a string :-). > `isearch-lazy-highlight-buffer-update' has more than one purpose, but I > assume that finishing faster is always better than taking longer than > necessary. In most real-life cases, at least in mine, you never need to look at all the matches, only at the first few. > However, the delay before the lazy count appears in the echo area during > day-to-day Isearch operation is noticeable to the naked eye. If you > keep looking, you will notice it. I know it's noticeable, and that directly contradicts your time estimations, because human eyes cannot notice such short delays. In general, anything shorter than 50 ms will look instantaneous to us, at least IME.