From unknown Fri Jun 20 07:23:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#29360 <29360@debbugs.gnu.org> To: bug#29360 <29360@debbugs.gnu.org> Subject: Status: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Reply-To: bug#29360 <29360@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:23:43 +0000 retitle 29360 26.0; Add full-buffer choice for `isearch-lazy-highlight' reassign 29360 emacs submitter 29360 Drew Adams severity 29360 wishlist tag 29360 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 19 14:06:14 2017 Received: (at submit) by debbugs.gnu.org; 19 Nov 2017 19:06:15 +0000 Received: from localhost ([127.0.0.1]:47935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGUv0-0007ta-Kq for submit@debbugs.gnu.org; Sun, 19 Nov 2017 14:06:14 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGUuz-0007tO-3x for submit@debbugs.gnu.org; Sun, 19 Nov 2017 14:06:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGUut-0001k7-4o for submit@debbugs.gnu.org; Sun, 19 Nov 2017 14:06:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34341) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGUut-0001jv-1P for submit@debbugs.gnu.org; Sun, 19 Nov 2017 14:06:07 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGUus-0002Ws-4f for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 14:06:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGUuo-0001hL-95 for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 14:06:06 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:43912) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGUuo-0001eO-1U for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2017 14:06:02 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAJJ5uuX014790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 19 Nov 2017 19:05:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAJJ5uhP009015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 19 Nov 2017 19:05:56 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAJJ5sBW004514 for ; Sun, 19 Nov 2017 19:05:56 GMT MIME-Version: 1.0 Message-ID: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> Date: Sun, 19 Nov 2017 11:05:54 -0800 (PST) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 26.0; Add full-buffer choice for `isearch-lazy-highlight' X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) See bug #21092 for the motivation and reasons behind this bug report. The aim of that bug report was never taken care of, which was to let you force lazy-highlight highlighting on the full visible portion of the buffer (where that refers to the full buffer or the current buffer restriction). IOW, optionally do not restrict highlighting to what is currently on screen, as is done now. The #21092 bug report mistakenly took a `nil' value of `lazy-highlight-max-at-a-time' as meaning just that - just what the doc said: act on the full buffer, not just on the text that is currently in the window. The true meaning of nil for that variable is just to highlight all of the search hits visible in the window. This new bug aims to finally get what was really being requested in #21092: the ability to cause lazy highlight to act on the full buffer, not just the text currently visible in the window. The outcome of #21092 and other bugs led to the creation of variable `isearch-lazy-highlight'. At the end of #21092, realizing that closing #21092 did not, in fact, respond to the aim of #21092, Juri suggested that a separate report be filed, to request a new possible value for `isearch-lazy-highlight' which will cause the full buffer to get the lazy-highlight highlighting. That is the purpose of this bug report: please add such a `buffer' or `full-buffer' value. In GNU Emacs 26.0.90 (build 3, x86_64-w64-mingw32) of 2017-10-13 Repository revision: 906224eba147bdfc0514090064e8e8f53160f1d4 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 20 16:00:28 2017 Received: (at 29360) by debbugs.gnu.org; 20 Nov 2017 21:00:28 +0000 Received: from localhost ([127.0.0.1]:49498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGtB6-0004uc-G1 for submit@debbugs.gnu.org; Mon, 20 Nov 2017 16:00:28 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:43757 helo=homiemail-a12.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGtB5-0004uU-C7 for 29360@debbugs.gnu.org; Mon, 20 Nov 2017 16:00:27 -0500 Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 5B0D926206A; Mon, 20 Nov 2017 13:00:26 -0800 (PST) Received: from localhost.linkov.net (m91-131-26-23.cust.tele2.ee [91.131.26.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 87B4D262065; Mon, 20 Nov 2017 13:00:25 -0800 (PST) From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> Date: Mon, 20 Nov 2017 22:53:55 +0200 In-Reply-To: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> (Drew Adams's message of "Sun, 19 Nov 2017 11:05:54 -0800 (PST)") Message-ID: <87shd8lli4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > See bug #21092 for the motivation and reasons behind this bug report. > The aim of that bug report was never taken care of, which was to let > you force lazy-highlight highlighting on the full visible portion of > the buffer (where that refers to the full buffer or the current > buffer restriction). IOW, optionally do not restrict highlighting > to what is currently on screen, as is done now. > > The #21092 bug report mistakenly took a `nil' value of > `lazy-highlight-max-at-a-time' as meaning just that - just what the doc > said: act on the full buffer, not just on the text that is currently in > the window. The true meaning of nil for that variable is just to > highlight all of the search hits visible in the window. > > This new bug aims to finally get what was really being requested in > #21092: the ability to cause lazy highlight to act on the full buffer, > not just the text currently visible in the window. > > The outcome of #21092 and other bugs led to the creation of variable > `isearch-lazy-highlight'. At the end of #21092, realizing that closing > #21092 did not, in fact, respond to the aim of #21092, Juri suggested > that a separate report be filed, to request a new possible value for > `isearch-lazy-highlight' which will cause the full buffer to get the > lazy-highlight highlighting. That is the purpose of this bug report: > please add such a `buffer' or `full-buffer' value. Are you sure this should be part of isearch, not hi-lock? Isearch used to highlight only the visible part of the buffer because it is modal and doesn't allow the user to scroll the current search match out of view. Whereas hi-lock is intended to highlight all matches in the whole buffer. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 20 17:41:04 2017 Received: (at 29360) by debbugs.gnu.org; 20 Nov 2017 22:41:04 +0000 Received: from localhost ([127.0.0.1]:49620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGukS-0002t4-J2 for submit@debbugs.gnu.org; Mon, 20 Nov 2017 17:41:04 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:30245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGukQ-0002sD-T4 for 29360@debbugs.gnu.org; Mon, 20 Nov 2017 17:41:03 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAKMet4i018467 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 22:40:55 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAKMesaQ015565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 22:40:54 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAKMeraQ001418; Mon, 20 Nov 2017 22:40:54 GMT MIME-Version: 1.0 Message-ID: <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> Date: Mon, 20 Nov 2017 14:40:52 -0800 (PST) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> In-Reply-To: <87shd8lli4.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > > See bug #21092 for the motivation and reasons behind this bug report. > > The aim of that bug report was never taken care of, which was to let > > you force lazy-highlight highlighting on the full visible portion of > > the buffer (where that refers to the full buffer or the current > > buffer restriction). IOW, optionally do not restrict highlighting > > to what is currently on screen, as is done now. > > > > The #21092 bug report mistakenly took a `nil' value of > > `lazy-highlight-max-at-a-time' as meaning just that - just what the doc > > said: act on the full buffer, not just on the text that is currently in > > the window. The true meaning of nil for that variable is just to > > highlight all of the search hits visible in the window. > > > > This new bug aims to finally get what was really being requested in > > #21092: the ability to cause lazy highlight to act on the full buffer, > > not just the text currently visible in the window. > > > > The outcome of #21092 and other bugs led to the creation of variable > > `isearch-lazy-highlight'. At the end of #21092, realizing that closing > > #21092 did not, in fact, respond to the aim of #21092, Juri suggested > > that a separate report be filed, to request a new possible value for > > `isearch-lazy-highlight' which will cause the full buffer to get the > > lazy-highlight highlighting. That is the purpose of this bug report: > > please add such a `buffer' or `full-buffer' value. >=20 > Are you sure this should be part of isearch, not hi-lock? Yes. > Isearch used to highlight only the visible part of the buffer Isearch also used to highlight only the current search hit - no lazy-highlighting at all. So what? Did someone back then argue that we shouldn't add lazy highlighting because Isearch is only about finding the next search hit? No. Highlighting all visible hits is an improvement over the pre-Emacs 22 behavior. Being able to optionally highlight all hits (visible in the window or not) adds other advantages. > because it is modal and doesn't allow the user to scroll the > current search match out of view. Whereas hi-lock is intended > to highlight all matches in the whole buffer. Just because Isearch has not previously had an option to highlight all matches is not a reason it should not offer such an option. This is only about _optional_ behavior; it proposes no change to the default lazy-highlighting behavior. No relation to hi-lock. This is not about font-lock highlighting. It is about the "lazy-highlighting"=20 of Isearch, during Isearch, for Isearch, being extended to cover the whole buffer. It is about incremental search: being able to change the set of matches incrementally. You can (now) set `lazy-highlight-cleanup' to nil (you can even toggle it during Isearch) to keep the lazy-highlighting when search is done. That can be very useful. And doing likewise without needing to totally exit Isearch can also be useful, e.g., to search only _within_ the lazy highlights - i.e., progressing search narrowing. E.g, combine multiple simple regexps (ANDing them) vs trying to come up with a single, complex regexp to do the same thing. Or being able to flip to searching the complement of the lazy highlights. Any such features expect, to be really useful, that the lazy-highlighted zones include all of the search hits, over the entire search space. They are about a new search that is related to the previous search. They should not be limited to whatever hits were visible in the current window for the previous search. Just because this is not the classic Isearch use case is not a reason it isn't usefully added to Isearch. It is only about isearching - isearching zones that have been found by isearching. It's about isearching isearches... Any argument about not being able to see highlighting past the window is irrelevant - this is not about scrolling. The motivation was already discussed in bug #21092. That bug should have taken care of this, but I expressed the need in terms of `lazy-highlight-max-at-a-time', having misunderstood that variable's purpose because its doc string described, for a nil value, just what this bug (#29360) asks for. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 23 16:51:53 2017 Received: (at 29360) by debbugs.gnu.org; 23 Nov 2017 21:51:53 +0000 Received: from localhost ([127.0.0.1]:54250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHzPV-0005gz-JO for submit@debbugs.gnu.org; Thu, 23 Nov 2017 16:51:53 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:57589 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHzPT-0005gr-PS for 29360@debbugs.gnu.org; Thu, 23 Nov 2017 16:51:52 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 6898476C06E; Thu, 23 Nov 2017 13:51:48 -0800 (PST) Received: from localhost.linkov.net (m91-131-26-23.cust.tele2.ee [91.131.26.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 96D8A76C06B; Thu, 23 Nov 2017 13:51:47 -0800 (PST) From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> Date: Thu, 23 Nov 2017 23:49:46 +0200 In-Reply-To: <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> (Drew Adams's message of "Mon, 20 Nov 2017 14:40:52 -0800 (PST)") Message-ID: <87efoomzr9.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> Are you sure this should be part of isearch, not hi-lock? > > No relation to hi-lock. This is not about font-lock > highlighting. hi-lock is not about font-lock highlighting too when font-lock is not active. See the variable =E2=80=98hi-lock-highlight-range=E2=80=99 with its default limit of 20000= 0. I'm thinking about using lazy-highlight in hi-lock to overcome this limitation after adding support for full-buffer to lazy-highlight. Maybe better to generalize the current implementation of isearch-lazy-highlight-update to apply a function given as an argument to perform different actions on the found matches (by default, adding the lazy-highlight overlay, and for hi-lock adding the hi-lock-overlay). From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 23 18:53:35 2017 Received: (at 29360) by debbugs.gnu.org; 23 Nov 2017 23:53:36 +0000 Received: from localhost ([127.0.0.1]:54383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eI1JH-0008Uf-N7 for submit@debbugs.gnu.org; Thu, 23 Nov 2017 18:53:35 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:24235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eI1JF-0008US-PS for 29360@debbugs.gnu.org; Thu, 23 Nov 2017 18:53:34 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vANNrRkN004179 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Nov 2017 23:53:27 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vANNrRah004078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Nov 2017 23:53:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vANNrQkh023100; Thu, 23 Nov 2017 23:53:26 GMT MIME-Version: 1.0 Message-ID: <314f93aa-a8b9-422b-af24-6755f0015b77@default> Date: Thu, 23 Nov 2017 15:53:25 -0800 (PST) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <87efoomzr9.fsf@mail.linkov.net> In-Reply-To: <87efoomzr9.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > >> Are you sure this should be part of isearch, not hi-lock? Yes, as I said. And I gave several reasons. > hi-lock is not about font-lock highlighting too > when font-lock is not active. See the variable > =E2=80=98hi-lock-highlight-range=E2=80=99 with its default limit of 20000= 0. >=20 > I'm thinking about using lazy-highlight in hi-lock > to overcome this limitation after adding support > for full-buffer to lazy-highlight. Maybe better > to generalize the current implementation of > isearch-lazy-highlight-update to apply a function > given as an argument to perform different actions > on the found matches (by default, adding the lazy-highlight > overlay, and for hi-lock adding the hi-lock-overlay). A hi-lock feature doesn't correspond at all to what I requested for this enhancement. I specifically want this as a feature of Isearch, for the reasons I gave. I guess I'll need to do this for only my own code. It's easy enough to do. I was hoping not to have to maintain yet another difference from vanilla Isearch, and to give vanilla Isearch the same potential benefits. Sorry I mentioned it now. After you do what you will do it will increase my maintenance burden rather than lessening it, and it won't move vanilla Emacs in the same direction. I already provide users a way to act on the current search hit in arbitrary ways. The default action is replacement - the default replacement is "" (delete). Your way of providing something similar will no doubt not offer exactly the same thing, and will anyway not use the same approach of implementation. No good deed goes unpunished, I guess. I suppose I should be happy to have inspired an improvement in Emacs, even if it's not the improvement I requested. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 18 01:47:43 2018 Received: (at 29360) by debbugs.gnu.org; 18 Oct 2018 05:47:43 +0000 Received: from localhost ([127.0.0.1]:56068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gD19r-0004Ol-8N for submit@debbugs.gnu.org; Thu, 18 Oct 2018 01:47:43 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:52074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gD19o-0004OT-Sk for 29360@debbugs.gnu.org; Thu, 18 Oct 2018 01:47:41 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9I5dExi008193; Thu, 18 Oct 2018 05:47:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=RThdXooNi58KsR9A/Okwxjdn0yaHO7VsmRJzu56pNW0=; b=L3sX2RQu0w+6GVGfLyForLMIS5xfQ1rLhUkUmurKFezeWUnW5xbGdSFwEW8l6dHu11i+ 3CxqAB78Vpa3LKpWTHkzM+gETEKDqV8grKokDeawuo+2sRYeaPxTt9MPELQBcUoO36sV p1qaJ8N1ZnoKbHHedWpC5185X9A76jg0Ba6hrwbb2oOEZvFg8tyuTh2RIYhGpQzZwOZg k3S+v2rv1brP0/JTMcDo8F/7vNGcMAnSIxG7CBmwfL1SCENWwD9bWvLeP4tihZTQOWPe rWx4CS20SRkE8SGwX2zoZ/q0zNFUjCwSq/uUwrDqcorYAp2Al+lGCDV7Fau1lE1WV6Si 8A== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2n39brm6y5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 05:47:34 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9I5lSN8022870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 05:47:28 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9I5lRTk004201; Thu, 18 Oct 2018 05:47:27 GMT MIME-Version: 1.0 Message-ID: <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> Date: Wed, 17 Oct 2018 22:47:26 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> In-Reply-To: <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9049 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=573 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180054 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Juri, It would really be good if this enhancement were made - for the reasons I gave in bug #21092, and for other reasons. You asked me (in bug #21092) to file this bug if I thought we needed such a full-buffer possibility. This enhancement request was the result. Did you not have a patch that took care of this? IIRC you then found a problem with it wrt `follow-mode', but I thought you had a solution for that too. (I thought the latter solution was provided by Artur's `all-windows' value for `isearch-lazy-highlight' etc., which was added.) There really is no comparison with hi-lock. Only Isearch provides incremental matching (with highlighting) for a regexp etc. Being able to try a search pattern, see the result as you type, adjust it, etc. is very handy. Then being able to leave the highlighting turned on (via nil `lazy-highlight-cleanup') means you can do all kinds of things with the resulting highlighted text. I do this now, but lack the ability to force highlighting the full buffer. That was my aim in bug #21092. What's the status of this feature? Can we add it to Emacs now? I hope so. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 18 18:40:39 2018 Received: (at 29360) by debbugs.gnu.org; 18 Oct 2018 22:40:39 +0000 Received: from localhost ([127.0.0.1]:57496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDGy7-0000zr-6d for submit@debbugs.gnu.org; Thu, 18 Oct 2018 18:40:39 -0400 Received: from pop.dreamhost.com ([64.90.62.162]:50144 helo=pdx1-sub0-mail-a25.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDGy4-0000zd-T5 for 29360@debbugs.gnu.org; Thu, 18 Oct 2018 18:40:37 -0400 Received: from pdx1-sub0-mail-a25.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a25.g.dreamhost.com (Postfix) with ESMTP id 8BC3B7FFE4; Thu, 18 Oct 2018 15:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=4cTlwTwhpDxYPRXIiZZ708b6qjg=; b= EdGmgiMu2Kb15MxlFvJ8KRWyW4d0FPC2BHJZsW9GkhUxNV5bkCvpnMRXlW4k1Mt3 iKbwik2xPNI9B36A6cLDf3HOMJ4vLuUu4WMSUemR0o7Rlxcam2JF9fh+/Pp+3AIu nplctDxI6X9LBLt1PtQpi1ftBcdu15FpsdSae650xQ0= Received: from mail.jurta.org (m91-129-96-249.cust.tele2.ee [91.129.96.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a25.g.dreamhost.com (Postfix) with ESMTPSA id E04B57FFE6; Thu, 18 Oct 2018 15:40:32 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a25 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> Date: Fri, 19 Oct 2018 01:18:21 +0300 In-Reply-To: <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> (Drew Adams's message of "Wed, 17 Oct 2018 22:47:26 -0700 (PDT)") Message-ID: <87va5yhpaq.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrfeehgdduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirddvgeelnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirddvgeelpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > It would really be good if this enhancement were made - for the > reasons I gave in bug #21092, and for other reasons. You asked me > (in bug #21092) to file this bug if I thought we needed such a > full-buffer possibility. This enhancement request was the result. Actually, a full-buffer lazy-highlighting possibility already exists: (setq lazy-highlight-cleanup nil) (add-hook 'isearch-mode-end-hook (lambda () (setq window-group-start-function (lambda (_w) (point-min))) (setq window-group-end-function (lambda (_w _u) (point-max))))) But I agree that more straightforward customization would be better with a clear value of the customizable variable. > Did you not have a patch that took care of this? IIRC you then found > a problem with it wrt `follow-mode', but I thought you had a solution > for that too. (I thought the latter solution was provided by Artur's > `all-windows' value for `isearch-lazy-highlight' etc., which was added.) That patch was installed more than a year ago. > What's the status of this feature? Can we add it to Emacs now? > I hope so. The reason why it's not yet finished is because it was unclear how to integrate it with another similar feature of matches-counting (that counts the number of matches in the full buffer). The reasoning is the following: both features require using the same loop in isearch-lazy-highlight extending it to operate on the full buffer. I know you will argue that these are unrelated features and should be treated separately. But implementation-wise they have only one difference: 1. buffer-matches-highlighting visits all matches and highlights them; 2. buffer-matches-counting visits all matches but doesn't highlight them (only counts) Both need special treatment for possible slowdown in a large buffer, so for performance reasons we need to add a new customizable variable like lazy-buffer-max-at-a-time, separate not to conflict with lazy-highlight-max-at-a-time. The latter applies to the matches on the screen, the former to the matches in the full buffer. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 18 19:25:14 2018 Received: (at 29360) by debbugs.gnu.org; 18 Oct 2018 23:25:14 +0000 Received: from localhost ([127.0.0.1]:57569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDHfG-0006QM-0D for submit@debbugs.gnu.org; Thu, 18 Oct 2018 19:25:14 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:54880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDHfE-0006Q7-90 for 29360@debbugs.gnu.org; Thu, 18 Oct 2018 19:25:12 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9INOUYP162713; Thu, 18 Oct 2018 23:25:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=SIUut8roxXVY49GmPXNkf9evzpox68O1U8rGlYvnhaM=; b=XnbQyqYNu0Kcg1u3AdIDXBm+aonxEgi8oOc/s6r7bN5r3/C7WEyeui7Aa2b0zVYPbwks slIiEMfCSrFzVX0EJQluw+ce40uHYynzq2V4a3zJ2j/HnbPazPIQD3gqcjoR+uNiEkUU iRyclOL5VOevGuhSN9VZucd1bbUbk8ouS99kJ+huLTH7oTvQ1sYBAmtMQFN/sTq+u86v sJE1mvQNELn/c+musZQMliu9xRY0MUd041VlxQL2nGtYPzkfLtSZ96dnQcHLVZYGoJs/ 2mRXDYLtf+pw45UIUJniG02q3TkG4nwH1afx/rmlkJ34GBjM3mCGz76HpcqfUUQKvEqc wA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2n38nqhasv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:25:05 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9INP4dq031912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:25:05 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9INP4tO004667; Thu, 18 Oct 2018 23:25:04 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 18 Oct 2018 16:25:03 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> In-Reply-To: <87va5yhpaq.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9050 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180197 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > It would really be good if this enhancement were made - for the > > reasons I gave in bug #21092, and for other reasons. You asked me > > (in bug #21092) to file this bug if I thought we needed such a > > full-buffer possibility. This enhancement request was the result. >=20 > Actually, a full-buffer lazy-highlighting possibility already exists: >=20 > (setq lazy-highlight-cleanup nil) > (add-hook 'isearch-mode-end-hook > (lambda () > (setq window-group-start-function (lambda (_w) (point-min))= ) > (setq window-group-end-function (lambda (_w _u) (point-max)= )))) Thanks for this info. I don't really understand it, though. `C-h v window-g= roup-start-function' tells me nothing, for instance - no doc, apparently. (FWIW, I already use `isearch-mode-end-hook' quite a bit. Not that another addition would necessarily break the bank. ;-)) > But I agree that more straightforward customization would be better > with a clear value of the customizable variable. Thank you. Will you please implement that when you get a chance? > > Did you not have a patch that took care of this? IIRC you then found > > a problem with it wrt `follow-mode', but I thought you had a solution > > for that too. (I thought the latter solution was provided by Artur's > > `all-windows' value for `isearch-lazy-highlight' etc., which was added.= ) >=20 > That patch was installed more than a year ago. What is that patch? Is this about `window-group-start|end-function' or is there some other way to force lazy highlighting to be done throughout the buffer? If this is patch is now reflected in isearch.el, where would I see it there? > > What's the status of this feature? Can we add it to Emacs now? > > I hope so. >=20 > The reason why it's not yet finished is because it was unclear how to > integrate it with another similar feature of matches-counting (that count= s > the number of matches in the full buffer). The reasoning is the followin= g: > both features require using the same loop in isearch-lazy-highlight > extending it to operate on the full buffer. I know you will argue that > these are unrelated features and should be treated separately. I won't argue any such thing, as I know nothing about this stuff. ;-) > But implementation-wise they have only one difference: >=20 > 1. buffer-matches-highlighting visits all matches and highlights them; > 2. buffer-matches-counting visits all matches but doesn't highlight them > (only counts) That doesn't sound like a big difference, a priori. Can't you just have a variable or a function argument that says whether to highlight? > Both need special treatment for possible slowdown in a > large buffer, so for performance reasons we need to add > a new customizable variable like lazy-buffer-max-at-a-time, > separate not to conflict with lazy-highlight-max-at-a-time. > The latter applies to the matches on the screen, the former > to the matches in the full buffer. I see. Sounds like that would be do-able, but I don't know anything about the details. Hope you can/will resolve this sometime soon. Thanks for taking a look. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 20 13:10:46 2018 Received: (at 29360) by debbugs.gnu.org; 20 Oct 2018 17:10:46 +0000 Received: from localhost ([127.0.0.1]:33413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDuly-0000Ko-8B for submit@debbugs.gnu.org; Sat, 20 Oct 2018 13:10:46 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:43764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDulw-0000Kc-RK for 29360@debbugs.gnu.org; Sat, 20 Oct 2018 13:10:45 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9KHA5K4115686; Sat, 20 Oct 2018 17:10:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=kpJXPSxiL2y96/D5hKX99uus8cH5s5MiL0jweRmYVqU=; b=SsUyL/liXGQkQCzub8q0DcS2GsUuukasLZSG1EUhcvEfUVmrWPYIVLSIYr7iHD68AyB3 AdsZNdAR6Mph+fA58r3ZqU8H+vVKVKlYMYvD2PgMFWjSj9+XoHdOWNQHZjFlomgvSEll NQuDGUJdo5orAQ6hWAaMvQBc06TS3QhfjQrngIW5HFdAqTg9wzJMx1p69m3ouDR7y371 hjkGtDBXHnS4N13EGgx86oWSy7ZZP0lXsTcwwb+GCagMfQnIurnSSD7cjGIb6oGtR3QB vUc11DREIdhCoNjE1/SUWkWYIe8R/Of7IXat9282ep9g1xn4SxQ3QdXCknGPR6HmbjWH 4w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2n7usts76g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 17:10:38 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9KHAcov016205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 17:10:38 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9KHAa6g014887; Sat, 20 Oct 2018 17:10:37 GMT MIME-Version: 1.0 Message-ID: <07011aa7-5e07-4783-abe5-96ee4bb9ce64@default> Date: Sat, 20 Oct 2018 10:10:35 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9052 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=532 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810200160 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Also, you said: > But I agree that more straightforward customization would be > better with a clear value of the customizable variable. I agree about the usefulness of having a user option for this. But here is one more consideration about that. Personally, I have no problem in general with commands that bind user options for their duration (and even with commands that set user option values), as long as their doc strings tell users that they do this. But I think it is vanilla-Emacs practice to forbid such programmatic changes of option values (even just during a command). If so, then please also allow also for programmatic use. Code should be able to bind a variable (non-option, if binding an option is verboten) to control whether lazy highlighting is full-buffer. That is, I believe that Isearch has several cases where there are both a user option and a non-option variable to control some behavior. That should be the case for full-buffer highlighting too. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 20 18:36:23 2018 Received: (at 29360) by debbugs.gnu.org; 20 Oct 2018 22:36:23 +0000 Received: from localhost ([127.0.0.1]:33584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzr5-0001m5-28 for submit@debbugs.gnu.org; Sat, 20 Oct 2018 18:36:23 -0400 Received: from pop.dreamhost.com ([64.90.62.162]:42410 helo=pdx1-sub0-mail-a10.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzr3-0001lx-B9 for 29360@debbugs.gnu.org; Sat, 20 Oct 2018 18:36:21 -0400 Received: from pdx1-sub0-mail-a10.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTP id C8A6580381; Sat, 20 Oct 2018 15:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=256dTsZHYbx4gJ/WLbimwp/Sd3U=; b= rsjkzkdiHrwkeC5y+yEvC7JFh4IMINNEjUWeUoQIZuPWKxA8denrvn4dY9JKCJRc Lv4bpCxzO2yDcw4qu1pX/GS7k5aSnizVnyCT7XeMuFHiNGKg4KcAL8HvlL/rHVfe VFPJGc+Wxrco9BdbMPSF0GlAJT8Rx202v3dyjsXi9nE= Received: from mail.jurta.org (m91-129-96-249.cust.tele2.ee [91.129.96.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 1547D8037B; Sat, 20 Oct 2018 15:36:18 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a10 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> Date: Sun, 21 Oct 2018 01:12:49 +0300 In-Reply-To: (Drew Adams's message of "Thu, 18 Oct 2018 16:25:03 -0700 (PDT)") Message-ID: <875zxwjlke.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrfeekgddujeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucffohhmrghinhepghhnuhdrohhrghenucfkphepledurdduvdelrdeliedrvdegleenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrvdegledprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Actually, a full-buffer lazy-highlighting possibility already exists: >> >> (setq lazy-highlight-cleanup nil) >> (add-hook 'isearch-mode-end-hook >> (lambda () >> (setq window-group-start-function (lambda (_w) (point-min))) >> (setq window-group-end-function (lambda (_w _u) (point-max))))) > > Thanks for this info. I don't really understand it, though. `C-h > v window-group-start-function' tells me nothing, for instance - no > doc, apparently. > > (FWIW, I already use `isearch-mode-end-hook' quite a bit. Not that another > addition would necessarily break the bank. ;-)) Sorry, I meant isearch-mode-hook, not isearch-mode-end-hook. But this detail is not important for properly implementing this feature. >> That patch was installed more than a year ago. > > What is that patch? Is this about `window-group-start|end-function' or > is there some other way to force lazy highlighting to be done throughout > the buffer? If this is patch is now reflected in isearch.el, where would > I see it there? It's here: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c5e66afa88d6ff8ad5c42318d85188ed477e7db2 >> Both need special treatment for possible slowdown in a >> large buffer, so for performance reasons we need to add >> a new customizable variable like lazy-buffer-max-at-a-time, >> separate not to conflict with lazy-highlight-max-at-a-time. >> The latter applies to the matches on the screen, the former >> to the matches in the full buffer. > > I see. Sounds like that would be do-able, but I don't know anything > about the details. Hope you can/will resolve this sometime soon. The biggest obstacle is this - currently the traversal order of visiting matches to lazy-highlight is the following: 1. start from the current match forward to the bottom of the window; 2. wrap from the bottom to the top of the window; 3. start from the top of the window down to the current match. Visually you can observe how the current algorithm works by setting: (setq lazy-highlight-max-at-a-time 1 lazy-highlight-initial-delay 1 lazy-highlight-interval 1) This works well when matches are highlighted only on the screen. But when boundaries will be extended from the window to the full buffer, the problem of performance creeps in. Lazy-highlighting will work in the following order: 1. start from the current match forward to the end of the buffer; 2. wrap from the end to the beginning of the buffer; 3. start from the beginning of the buffer down to the current match. The problem is that matches in the upper part of the window might be highlighted too late - only when all matches in the full buffer are highlighted, and most of these matches likely will be outside of the displayed part of the buffer in the window. IOW, highlighting of the matches above the current match will be delayed until all other matches in the whole buffer will get a highlighting overlay. Do you think we should change the algorithm and adapt it to highlighting of the buffer? Maybe we should first highlight matches on the bottom and the top part of the window before going to highlight matches in other parts of the buffer that are not visible on the screen? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 20 19:09:40 2018 Received: (at 29360) by debbugs.gnu.org; 20 Oct 2018 23:09:40 +0000 Received: from localhost ([127.0.0.1]:33596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE0NI-0002Zb-3b for submit@debbugs.gnu.org; Sat, 20 Oct 2018 19:09:40 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:55612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE0NF-0002ZO-Qv for 29360@debbugs.gnu.org; Sat, 20 Oct 2018 19:09:38 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9KN9VH0125875; Sat, 20 Oct 2018 23:09:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=oxPIWv0JZCAuYCO7YAB2GSkrjcFgnY7ORYniychoiv0=; b=w+CSJudazvqBGFvhjYs74viZYauz8JNI7ZFP5vtRSWPMnCeOAM9ur576SRddQ2nMVoFR SkwT6KZV3I41JabbUO5n9UsK45w2mjBbqIpwnSwsceQlCPZchPTh9hUbEWPNRbHpqqAF ikotTQE1CVJafxqL6NPJ4RA4Kq46ot+qtWl3BlG1yZvzuCtuPcGsW7GEo5L/MG5ZzyKw Ye23m9Z9T0Ijh5wL4sYFOrErG7mVrPBbFPaRQkxvA5iHD9ywM4tLSg2CtuoDdypiEsN+ Z0n01y71STdyDrBTn51x0YGQ6+k0UOJemrdzwx2Zq0bvJDfpF+jUAYu/qlkJwH+ejb31 AQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2n7vaphga5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 23:09:31 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9KN9Uli003959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 23:09:30 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9KN9UE6011590; Sat, 20 Oct 2018 23:09:30 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 20 Oct 2018 16:09:29 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> In-Reply-To: <875zxwjlke.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9052 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810200215 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The biggest obstacle is this - currently the traversal order of > visiting matches to lazy-highlight is the following: >=20 > 1. start from the current match forward to the bottom of the window; >=20 > 2. wrap from the bottom to the top of the window; >=20 > 3. start from the top of the window down to the current match. >=20 > Visually you can observe how the current algorithm works by setting: >=20 > (setq lazy-highlight-max-at-a-time 1 > lazy-highlight-initial-delay 1 > lazy-highlight-interval 1) >=20 > This works well when matches are highlighted only on the screen. >=20 > But when boundaries will be extended from the window to the full buffer, > the problem of performance creeps in. Lazy-highlighting will work > in the following order: >=20 > 1. start from the current match forward to the end of the buffer; >=20 > 2. wrap from the end to the beginning of the buffer; >=20 > 3. start from the beginning of the buffer down to the current match. >=20 > The problem is that matches in the upper part of the window might be > highlighted too late - only when all matches in the full buffer > are highlighted, and most of these matches likely will be outside > of the displayed part of the buffer in the window. >=20 > IOW, highlighting of the matches above the current match will be delayed > until all other matches in the whole buffer will get a highlighting > overlay. >=20 > Do you think we should change the algorithm and adapt it to highlighting > of the buffer? Maybe we should first highlight matches on the bottom > and the top part of the window before going to highlight matches in > other parts of the buffer that are not visible on the screen? Thanks for the explanation - very clear. I don't have any brilliant insight into this. I'd imagine that most uses of full-buffer highlighting are either: 1. On relatively small buffers, just for convenience of getting it all done at once (i.e., non-lazy). 2. On any size buffer, for some other purpose than just Isearch. IOW, use Isearch as a UI to get parts of a buffer highlighted (and so propertized), for other purposes than just Isearch. I'm not sure that #1 is a real use case. If it is then it's anyway not problematic for the problem you mention - by definition. It may be that for many of the #2 use cases immediate response for the Isearch part is not that important. (Dunno.) In any case, yes, your suggestion of first doing what we do now (highlight the immediate area, using the current algorith), and then following that with highlighting the rest of the buffer, could be a good idea. Dunno how much that might change the existing code. Another possibility (?) is that for some of the #2 use cases it might even be enough to highlight the rest of the buffer when Emacs is idle. Again, dunno whether that option would be important. But if we do that it should be controllable by users and program, I'd think. You likely have better ideas about all this. These are just a few thoughts that came to mind now. (BTW, I already sometimes see Isearch paint the lazy-highlighting slowly, eventually coming down from the top of the window. Not sure what the circumstances are in which I see that sometimes. Probably when matching takes longer for some reason.) From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 21 15:19:12 2018 Received: (at 29360) by debbugs.gnu.org; 21 Oct 2018 19:19:12 +0000 Received: from localhost ([127.0.0.1]:34588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEJFo-0004HA-2g for submit@debbugs.gnu.org; Sun, 21 Oct 2018 15:19:12 -0400 Received: from pop.dreamhost.com ([64.90.62.162]:57612 helo=pdx1-sub0-mail-a61.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEJFl-0004H2-O6 for 29360@debbugs.gnu.org; Sun, 21 Oct 2018 15:19:10 -0400 Received: from pdx1-sub0-mail-a61.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTP id 4AE9D80005; Sun, 21 Oct 2018 12:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=g8PyZoSAWbTeLV5IF42hTvUb8nA=; b= CvBovXE9y8iNRgqx1GnRLQECyahPl9HSJy4wQJw5U49R5JyYWXym/vUsV+2jMsEf PtssEU1x6qig0X3ehBievMDDPbQMEiDRWWKY2cltcAEojPGJ0eZGDLZKdzm0DUFi Svn1HjrPMWSaHy6tzP2FyzZShxpKZDdkXvFABpmYXPU= Received: from mail.jurta.org (m91-129-96-249.cust.tele2.ee [91.129.96.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a61.g.dreamhost.com (Postfix) with ESMTPSA id DAF1D7FFF8; Sun, 21 Oct 2018 12:19:07 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a61 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> Date: Sun, 21 Oct 2018 22:06:48 +0300 In-Reply-To: (Drew Adams's message of "Sat, 20 Oct 2018 16:09:29 -0700 (PDT)") Message-ID: <87woqbglvb.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrgedtgddufeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesmhdtreertdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdeliedrvdegleenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrvdegledprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain > In any case, yes, your suggestion of first doing what we do now > (highlight the immediate area, using the current algorith), and > then following that with highlighting the rest of the buffer, > could be a good idea. Dunno how much that might change > the existing code. In the patch attached below, a new function isearch-lazy-highlight-buffer-update is a copy of isearch-lazy-highlight-update with some changes specific to highlighting the full buffer. It seems making a duplicate function is necessary because adding more full-buffer specific conditions to the existing function isearch-lazy-highlight-update will make it unmaintainable. Only a part of the function (that highlights the match) is extracted into a new function isearch-lazy-highlight-match and shared among these aforementioned two functions. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=isearch-lazy-highlight-buffer.1.patch diff --git a/lisp/isearch.el b/lisp/isearch.el index 1e785a44c5..cb9e72526b 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -304,7 +304,7 @@ isearch-fail (defcustom isearch-lazy-highlight t "Controls the lazy-highlighting during incremental search. -When non-nil, all text in the buffer matching the current search +When non-nil, all text on the screen matching the current search string is highlighted lazily (see `lazy-highlight-initial-delay' and `lazy-highlight-interval'). @@ -316,6 +316,15 @@ isearch-lazy-highlight :group 'lazy-highlight :group 'isearch) +(defcustom isearch-lazy-highlight-buffer nil + "Controls the lazy-highlighting of the whole buffer. +When non-nil, all text in the buffer matching the current search +string is highlighted lazily (see `lazy-highlight-initial-delay', +`lazy-highlight-interval' and `lazy-highlight-buffer-max-at-a-time')." + :type 'boolean + :group 'lazy-highlight + :group 'isearch) + ;;; Lazy highlight customization. (defgroup lazy-highlight nil @@ -351,6 +360,15 @@ lazy-highlight-max-at-a-time (integer :tag "Some")) :group 'lazy-highlight) +(defcustom lazy-highlight-buffer-max-at-a-time 20 + "Maximum matches to highlight at a time (for `isearch-lazy-highlight-buffer'). +Larger values may reduce Isearch's responsiveness to user input; +smaller values make matches highlight slowly. +A value of nil means highlight all matches shown in the buffer." + :type '(choice (const :tag "All" nil) + (integer :tag "Some")) + :group 'lazy-highlight) + (defface lazy-highlight '((((class color) (min-colors 88) (background light)) (:background "paleturquoise")) @@ -3290,13 +3308,13 @@ isearch-lazy-highlight-search (+ isearch-lazy-highlight-start ;; Extend bound to match whole string at point (1- (length isearch-lazy-highlight-last-string))) - (window-group-end))) + (if isearch-lazy-highlight-buffer (point-max) (window-group-end)))) (max (or isearch-lazy-highlight-start-limit (point-min)) (if isearch-lazy-highlight-wrapped (- isearch-lazy-highlight-end ;; Extend bound to match whole string at point (1- (length isearch-lazy-highlight-last-string))) - (window-group-start)))))) + (if isearch-lazy-highlight-buffer (point-min) (window-group-start))))))) ;; Use a loop like in `isearch-search'. (while retry (setq success (isearch-search-string @@ -3317,6 +3335,20 @@ isearch-lazy-highlight-start (lazy-highlight-cleanup t) ;remove old overlays (isearch-lazy-highlight-update)) +(defvar isearch-lazy-highlight-match-function #'isearch-lazy-highlight-match + "Function that highlights the found match. +The function accepts two arguments: the beginning and the end of the match.") + +(defun isearch-lazy-highlight-match (mb me) + (let ((ov (make-overlay mb me))) + (push ov isearch-lazy-highlight-overlays) + ;; 1000 is higher than ediff's 100+, + ;; but lower than isearch main overlay's 1001 + (overlay-put ov 'priority 1000) + (overlay-put ov 'face 'lazy-highlight) + (unless (eq isearch-lazy-highlight 'all-windows) + (overlay-put ov 'window (selected-window))))) + (defun isearch-lazy-highlight-update () "Update highlighting of other matches for current search." (let ((max lazy-highlight-max-at-a-time) @@ -3353,16 +3385,8 @@ isearch-lazy-highlight-update (window-group-start))) (setq found nil) (forward-char -1))) - ;; non-zero-length match - (let ((ov (make-overlay mb me))) - (push ov isearch-lazy-highlight-overlays) - ;; 1000 is higher than ediff's 100+, - ;; but lower than isearch main overlay's 1001 - (overlay-put ov 'priority 1000) - (overlay-put ov 'face 'lazy-highlight) - (unless (eq isearch-lazy-highlight 'all-windows) - (overlay-put ov 'window (selected-window))))) + (funcall isearch-lazy-highlight-match-function mb me)) ;; Remember the current position of point for ;; the next call of `isearch-lazy-highlight-update' ;; when `lazy-highlight-max-at-a-time' is too small. @@ -3384,11 +3408,75 @@ isearch-lazy-highlight-update (setq isearch-lazy-highlight-start (window-group-end)) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) (window-group-end)))))))) - (unless nomore + (if nomore + (when isearch-lazy-highlight-buffer + (setq isearch-lazy-highlight-start (window-group-start)) + (setq isearch-lazy-highlight-end (window-group-end)) + (setq isearch-lazy-highlight-wrapped nil) + (run-at-time lazy-highlight-interval nil + 'isearch-lazy-highlight-buffer-update)) (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil 'isearch-lazy-highlight-update))))))))) +(defun isearch-lazy-highlight-buffer-update () + "Update highlighting of other matches in the whole buffer." + (let ((max lazy-highlight-buffer-max-at-a-time) + (looping t) + nomore) + (with-local-quit + (save-excursion + (save-match-data + (goto-char (if isearch-lazy-highlight-forward + isearch-lazy-highlight-end + isearch-lazy-highlight-start)) + (while looping + (let ((found (isearch-lazy-highlight-search))) + (when max + (setq max (1- max)) + (if (<= max 0) + (setq looping nil))) + (if found + (let ((mb (match-beginning 0)) + (me (match-end 0))) + (if (= mb me) ;zero-length match + (if isearch-lazy-highlight-forward + (if (= mb (if isearch-lazy-highlight-wrapped + (window-group-start) + (point-max))) + (setq found nil) + (forward-char 1)) + (if (= mb (if isearch-lazy-highlight-wrapped + (window-group-end) + (point-min))) + (setq found nil) + (forward-char -1))) + ;; non-zero-length match + (funcall isearch-lazy-highlight-match-function mb me)) + ;; Remember the current position of point for + ;; the next call of `isearch-lazy-highlight-update' + ;; when `lazy-highlight-max-at-a-time' is too small. + (if isearch-lazy-highlight-forward + (setq isearch-lazy-highlight-end (point)) + (setq isearch-lazy-highlight-start (point))))) + ;; not found or zero-length match at the search bound + (if (not found) + (if isearch-lazy-highlight-wrapped + (setq looping nil + nomore t) + (setq isearch-lazy-highlight-wrapped t) + (if isearch-lazy-highlight-forward + (progn + (setq isearch-lazy-highlight-end (point-min)) + (goto-char (point-min))) + (setq isearch-lazy-highlight-start (point-max)) + (goto-char (point-max))))))) + (if nomore + (message "Finished lazy-highlighting the buffer") + (setq isearch-lazy-highlight-timer + (run-at-time lazy-highlight-interval nil + 'isearch-lazy-highlight-buffer-update)))))))) + (defun isearch-resume (string regexp word forward message case-fold) "Resume an incremental search. STRING is the string or regexp searched for. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 21 23:33:51 2018 Received: (at 29360) by debbugs.gnu.org; 22 Oct 2018 03:33:51 +0000 Received: from localhost ([127.0.0.1]:34973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEQyU-00079k-QL for submit@debbugs.gnu.org; Sun, 21 Oct 2018 23:33:51 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:45640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEQyS-00079X-NG for 29360@debbugs.gnu.org; Sun, 21 Oct 2018 23:33:49 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9M3XYec167988; Mon, 22 Oct 2018 03:33:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=/QrRIaKjW6jPvYzDkCjrVPKBkLAZRPMBDe6f6YJlGOg=; b=VRjC+QcobnT+pFVzEEkuf50Is1vZHThJvQcTMjKWUlIg5MC7ULa/9SRXFwcMc06SbgXt 4PcHPBMeninC7cXOBBPCzV4hbVuw7x+JTYD8lR5S79vTTHoJdMUQgrOQ3YgXU45SUtWj OC19AcR9LgSxYK78Lf/39G6+9pUUpqE5w4FUR8uvaWpRAuXEY9wQVZSPKZwkSoBORs1c 6/sPtcqfYCwMvmg5kwWL5Or7Kc+77lly8WypA6tRokWzeu6rLyAQ8jWvOyY2U5waKU/M J3PPTgQ+Z3Gb/6SzitUhoDur/YAUCD3wa2mqAoeJRTWI4kYQnMWIX2zGBixNfAiwbO4O Kw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2n7ustuxhw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 03:33:42 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9M3Xaj2003364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 03:33:37 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9M3Xa1H003390; Mon, 22 Oct 2018 03:33:36 GMT MIME-Version: 1.0 Message-ID: <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> Date: Sun, 21 Oct 2018 20:33:35 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> In-Reply-To: <87woqbglvb.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9053 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810220033 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > In any case, yes, your suggestion of first doing what we do now > > (highlight the immediate area, using the current algorith), and > > then following that with highlighting the rest of the buffer, > > could be a good idea. Dunno how much that might change > > the existing code. >=20 > In the patch attached below, a new function isearch-lazy-highlight-buffer= - > update > is a copy of isearch-lazy-highlight-update with some changes specific > to highlighting the full buffer. It seems making a duplicate function > is necessary because adding more full-buffer specific conditions to > the existing function isearch-lazy-highlight-update will make it > unmaintainable. >=20 > Only a part of the function (that highlights the match) is extracted > into a new function isearch-lazy-highlight-match and shared among these > aforementioned two functions. Thanks for doing this. A cursory check tells me it works. One main comment and a couple of minor ones. 1. The main one is to remind you of what I said earlier: > [P]lease also allow also for programmatic use. Code > should be able to bind a variable (non-option, if binding an > option is verboten) to control whether lazy highlighting is > full-buffer. > > That is, I believe that Isearch has several cases where there > are both a user option and a non-option variable to control some > behavior. That should be the case for full-buffer highlighting too. As also stated earlier, I expect that the main use cases will involve using "Isearch as a UI to get parts of a buffer highlighted (and so propertized), for other purposes than just Isearch." Would you please consider adding such non-option variable control? I don't need it for my own code, because I don't hesitate to offer commands that bind user options. But vanilla Emacs feels differently. 2. Please think about changing "on the screen" (it's in a couple places) to something like "currently visible in the window". (Or "currently visible on the screen" if you want this to apply to multiple windows.) This is actually something that's bothered me before, but it becomes more important now that we've introduced the possibility of highlighting "beyond the screen", so to speak. My concern here is that "on the screen" can be misinterpreted as more than just the text that is currently shown. Even talking about the text that is "in" a window is problematic for someone who hasn't gotten acquainted with Emacs jargon. A user can mistakenly think that all of a buffer's text is "in" a window that shows the buffer, even the parts that are not currently shown there. We should try to somehow get across the fact that only text in parts of the buffer that you show by scrolling to it gets highlighted. Yes, there could be some confusion regarding invisible text if we say something like currently "visible" or "shown". But I don't think "on the screen" is clear enough. It's not obvious to a user that there is some text in the buffer that is not "on the screen". Maybe it would be best to explicitly state what's involved, at each place where we speak of "screen" - including perhaps `isearch-allow-scroll'. Perhaps say that unless `isearch-lazy-highlight-buffer' is non-nil lazy highlighting highlights only the parts of the buffer you can currently see (but that other parts already highlighted remain highlighted). Also, as a casual user might well wonder why we have option `isearch-lazy-highlight-buffer', it might be good to mention a use case: you might want to highlight all occurrences and then process all of them programmatically. (And mention option `lazy-highlight-cleanup', for instance.) Dunno how important this is, as most users will neither look at `isearch-lazy-highlight-buffer' nor imagine that they might want to highlight text that they don't yet see. But for a user who does, it could help to give them the idea that they might do something with the highlighted text. 3. Finally, I think that lazy-highlighting the full buffer will typically go hand in hand with keeping the highlighting. That is, non-nil `isearch-lazy-highlight-buffer' will be used with nil `isearch-lazy-highlight-cleanup', and vice versa. It might be useful to make it easy to couple the two. (In my own code, at least, I've added a key that toggles `isearch-lazy-highlight-buffer' and sets `isearch-lazy-highlight-cleanup' to `(not isearch-lazy-highlight-buffer)'. I know that Emacs won't want keys that toggle option values, so I'm not sure what Emacs would want to do to make it easy for a user to couple the two.) 4. Another possible addition might be an indicator somewhere (in the prompt? lighter?) to show that lazy highlighting is in progress. Dunno whether that's needed. It's good that you added the message letting you know when it's done. Thanks again for implementing this feature. I think you can close this bug now. I've played with it a bit, and it seems to work fine. - Drew From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 23 18:07:45 2018 Received: (at 29360) by debbugs.gnu.org; 23 Oct 2018 22:07:45 +0000 Received: from localhost ([127.0.0.1]:38691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gF4q1-00009v-40 for submit@debbugs.gnu.org; Tue, 23 Oct 2018 18:07:45 -0400 Received: from pop.dreamhost.com ([64.90.62.162]:36734 helo=pdx1-sub0-mail-a73.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gF4pz-00009n-9d for 29360@debbugs.gnu.org; Tue, 23 Oct 2018 18:07:43 -0400 Received: from pdx1-sub0-mail-a73.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a73.g.dreamhost.com (Postfix) with ESMTP id 89DE08023A; Tue, 23 Oct 2018 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=oeUOPCm372likNtYdfW7G3pma18=; b= XnQyUvW5r70wE3819ADCCydrP86ZGafNb4yOKfPuPKxchXYFmbX+l7OV957h3TTJ jDCOK0kMBMfkDwVSCmUgm7XpHLMoQ+Xs/AfoosvkbpO5USVo9kKR3Ilkypk+VQuF DODnnKKxq2US9IuLOOn6KI7jvvNgY3yQTCUvTtqBzV0= Received: from mail.jurta.org (m91-129-96-249.cust.tele2.ee [91.129.96.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 44D6680229; Tue, 23 Oct 2018 15:07:40 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a73 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> Date: Wed, 24 Oct 2018 01:05:17 +0300 In-Reply-To: <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> (Drew Adams's message of "Sun, 21 Oct 2018 20:33:35 -0700 (PDT)") Message-ID: <87efcguxnm.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrgeehgddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirddvgeelnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirddvgeelpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Thanks for doing this. A cursory check tells me it works. Bad news: when I tried to type an isearch string on a large file (about 1MB) after typing the first character 'e' lazy-highlighting became unresponsive busy highlighting all 50000 matches in that file. Do you think we should start lazy-highlighting for the full buffer only when the length of the search string is more than 1 character? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 23 18:51:23 2018 Received: (at 29360) by debbugs.gnu.org; 23 Oct 2018 22:51:24 +0000 Received: from localhost ([127.0.0.1]:38811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gF5WF-0005Od-LZ for submit@debbugs.gnu.org; Tue, 23 Oct 2018 18:51:23 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:55018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gF5WE-0005OR-2U for 29360@debbugs.gnu.org; Tue, 23 Oct 2018 18:51:22 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9NMiMdX170082; Tue, 23 Oct 2018 22:51:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=yQHV2ltf/oVAuPA0a0daHVHblCsxScko7oLWhgP5cKQ=; b=cLPJkOQwESL6jE2u+O0rjNfzaqM3T5/gmd5kXv4XzZIJguHhrM9u7NZX09rFFI2LgkAd HsHSLzcsP3WBlRje4Uy6NJxHKQH06r3Q9UaY6jbeQWJD6soXJSzPnXT7LGqmVajAloP9 mu7/yC+FOcLYe5Lbc8/UfY1+zZhJe0Uk8eyQbC0Ic3lQYsyuwHAS+8BlVrP4NYccRUqy PKC0mtX1li8CK/W0xsTqwvdRX81nkU8denHZGNwRc4FaP9gjFTychy2UwT441L7fYWaG 9l/vfOrzfe2QFnK1v+IaEMkKV5BCtZ0UO+t7JfBWfmM/G927d1trx7w5guJ9d2fPlO50 qA== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2n7vaq08vh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 22:51:15 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9NMpFB6030731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Oct 2018 22:51:15 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9NMpEuK032150; Tue, 23 Oct 2018 22:51:14 GMT MIME-Version: 1.0 Message-ID: <3818ac4c-6564-4439-9fb5-c84791f43f7a@default> Date: Tue, 23 Oct 2018 15:51:14 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> <87efcguxnm.fsf@mail.linkov.net> In-Reply-To: <87efcguxnm.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9055 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=697 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230186 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Bad news: when I tried to type an isearch string on a large file > (about 1MB) after typing the first character 'e' lazy-highlighting > became unresponsive busy highlighting all 50000 matches in that file. >=20 > Do you think we should start lazy-highlighting for the full buffer > only when the length of the search string is more than 1 character? Absolutely. Like with any similar interaction in Emacs the delay before starting should be a user option. Users are different, and user machines etc. are different. Another possibility is for the option value to be a choice of either: * A non-negative number of seconds (or maybe natnump) * A cons (SIZE . DELAY), where SIZE is the buffer-size=20 threshold: no delay if the buffer is no larger than this, and DELAY seconds delay if greater than this. Another possibility, to accomplish the same thing (delay and threshold) is to have two different options: lazy-highlight-delay - just the delay lazy-highlight-threshold - just the size threshold The latter approach is what I use in Icicles, for several such settings, e.g. `icicle-incremental-completion-delay' and `icicle-incremental-completion-threshold' But maybe the former approach is simpler. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 24 19:45:58 2018 Received: (at 29360) by debbugs.gnu.org; 24 Oct 2018 23:45:58 +0000 Received: from localhost ([127.0.0.1]:41025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFSqb-0001aL-OI for submit@debbugs.gnu.org; Wed, 24 Oct 2018 19:45:58 -0400 Received: from bonobo.maple.relay.mailchannels.net ([23.83.214.22]:12445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFSqZ-0001aB-1m for 29360@debbugs.gnu.org; Wed, 24 Oct 2018 19:45:56 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A47875E3610; Wed, 24 Oct 2018 23:45:53 +0000 (UTC) Received: from pdx1-sub0-mail-a38.g.dreamhost.com (unknown [100.96.16.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5C12B5E364A; Wed, 24 Oct 2018 23:45:53 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a38.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Wed, 24 Oct 2018 23:45:53 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Chemical-Shrill: 3ed1fa8e2252e03b_1540424753469_3199655950 X-MC-Loop-Signature: 1540424753469:801957953 X-MC-Ingress-Time: 1540424753468 Received: from pdx1-sub0-mail-a38.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a38.g.dreamhost.com (Postfix) with ESMTP id 16BBC803C0; Wed, 24 Oct 2018 16:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=32d7mPpEzj4F7Mk9MEL+qRMVyYc=; b= epZxPoefHVdabjmOToPEZtv+sZ6VwqD2Xb096g81V+aoZhf9p0YB8/rXGD8R2mkL naAX/9Et1VH0bnoprADVPs0EXtW5Hk7ovHE7zltVc78rInQhDi947+S3q0pvnvj1 M6tlWDg+hgL4HeyQtpk+AFKyGNuPLdHlT+1/A3kC9Kc= Received: from mail.jurta.org (m91-129-105-154.cust.tele2.ee [91.129.105.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a38.g.dreamhost.com (Postfix) with ESMTPSA id BCE4C803B9; Wed, 24 Oct 2018 16:45:50 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a38 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> <87efcguxnm.fsf@mail.linkov.net> <3818ac4c-6564-4439-9fb5-c84791f43f7a@default> Date: Thu, 25 Oct 2018 02:11:25 +0300 In-Reply-To: <3818ac4c-6564-4439-9fb5-c84791f43f7a@default> (Drew Adams's message of "Tue, 23 Oct 2018 15:51:14 -0700 (PDT)") Message-ID: <87sh0vaqjm.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrgeekgddviecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehmtderredtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddthedrudehgeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdehrdduheegpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain > Absolutely. Like with any similar interaction in > Emacs the delay before starting should be a user > option. Users are different, and user machines etc. > are different. You are right, with a small delay lazy-highlighting is responsive. In the attached patch I also added a separate variable that you asked for programmatic use, changed text to "currently visible on the screen" and mentioned lazy-highlight-cleanup. The patch is extensively tested for various scenarios: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=isearch-lazy-highlight-buffer.2.patch diff --git a/lisp/isearch.el b/lisp/isearch.el index 1e785a44c5..dae85208cb 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -304,9 +304,9 @@ isearch-fail (defcustom isearch-lazy-highlight t "Controls the lazy-highlighting during incremental search. -When non-nil, all text in the buffer matching the current search -string is highlighted lazily (see `lazy-highlight-initial-delay' -and `lazy-highlight-interval'). +When non-nil, all text currently visible on the screen +matching the current search string is highlighted lazily +(see `lazy-highlight-initial-delay' and `lazy-highlight-interval'). When multiple windows display the current buffer, the highlighting is displayed only on the selected window, unless @@ -316,6 +316,17 @@ isearch-lazy-highlight :group 'lazy-highlight :group 'isearch) +(defcustom isearch-lazy-highlight-buffer nil + "Controls the lazy-highlighting of the full buffer. +When non-nil, all text in the buffer matching the current search +string is highlighted lazily (see `lazy-highlight-initial-delay', +`lazy-highlight-interval' and `lazy-highlight-buffer-max-at-a-time'). +This is useful when `lazy-highlight-cleanup' is customized to nil +and doesn't remove full-buffer highlighting after a search." + :type 'boolean + :group 'lazy-highlight + :group 'isearch) + ;;; Lazy highlight customization. (defgroup lazy-highlight nil @@ -351,6 +362,15 @@ lazy-highlight-max-at-a-time (integer :tag "Some")) :group 'lazy-highlight) +(defcustom lazy-highlight-buffer-max-at-a-time 20 + "Maximum matches to highlight at a time (for `isearch-lazy-highlight-buffer'). +Larger values may reduce Isearch's responsiveness to user input; +smaller values make matches highlight slowly. +A value of nil means highlight all matches shown in the buffer." + :type '(choice (const :tag "All" nil) + (integer :tag "Some")) + :group 'lazy-highlight) + (defface lazy-highlight '((((class color) (min-colors 88) (background light)) (:background "paleturquoise")) @@ -3178,6 +3198,7 @@ isearch-lazy-highlight-window (defvar isearch-lazy-highlight-window-group nil) (defvar isearch-lazy-highlight-window-start nil) (defvar isearch-lazy-highlight-window-end nil) +(defvar isearch-lazy-highlight-buffer-p nil) (defvar isearch-lazy-highlight-case-fold-search nil) (defvar isearch-lazy-highlight-regexp nil) (defvar isearch-lazy-highlight-lax-whitespace nil) @@ -3226,10 +3247,12 @@ isearch-lazy-highlight-new-loop isearch-lax-whitespace)) (not (eq isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace)) - (not (= (window-group-start) - isearch-lazy-highlight-window-start)) - (not (= (window-group-end) ; Window may have been split/joined. - isearch-lazy-highlight-window-end)) + (not (or isearch-lazy-highlight-buffer-p + (= (window-group-start) + isearch-lazy-highlight-window-start))) + (not (or isearch-lazy-highlight-buffer-p + (= (window-group-end) ; Window may have been split/joined. + isearch-lazy-highlight-window-end))) (not (eq isearch-forward isearch-lazy-highlight-forward)) ;; In case we are recovering from an error. @@ -3247,6 +3270,7 @@ isearch-lazy-highlight-new-loop isearch-lazy-highlight-window-group (selected-window-group) isearch-lazy-highlight-window-start (window-group-start) isearch-lazy-highlight-window-end (window-group-end) + isearch-lazy-highlight-buffer-p isearch-lazy-highlight-buffer ;; Start lazy-highlighting at the beginning of the found ;; match (`isearch-other-end'). If no match, use point. ;; One of the next two variables (depending on search direction) @@ -3264,12 +3288,22 @@ isearch-lazy-highlight-new-loop isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace isearch-lazy-highlight-regexp-function isearch-regexp-function isearch-lazy-highlight-forward isearch-forward) + ;; Extend start/end to match whole string at point + (if isearch-lazy-highlight-forward + (setq isearch-lazy-highlight-start + (min (+ isearch-lazy-highlight-start + (1- (length isearch-lazy-highlight-last-string))) + (point-max))) + (setq isearch-lazy-highlight-end + (max (- isearch-lazy-highlight-end + (1- (length isearch-lazy-highlight-last-string))) + (point-min)))) (unless (equal isearch-string "") (setq isearch-lazy-highlight-timer (run-with-idle-timer lazy-highlight-initial-delay nil 'isearch-lazy-highlight-start))))) -(defun isearch-lazy-highlight-search () +(defun isearch-lazy-highlight-search (string bound) "Search ahead for the next or previous match, for lazy highlighting. Attempt to do the search exactly the way the pending Isearch would." (condition-case nil @@ -3283,24 +3317,10 @@ isearch-lazy-highlight-search (isearch-forward isearch-lazy-highlight-forward) (search-invisible nil) ; don't match invisible text (retry t) - (success nil) - (bound (if isearch-lazy-highlight-forward - (min (or isearch-lazy-highlight-end-limit (point-max)) - (if isearch-lazy-highlight-wrapped - (+ isearch-lazy-highlight-start - ;; Extend bound to match whole string at point - (1- (length isearch-lazy-highlight-last-string))) - (window-group-end))) - (max (or isearch-lazy-highlight-start-limit (point-min)) - (if isearch-lazy-highlight-wrapped - (- isearch-lazy-highlight-end - ;; Extend bound to match whole string at point - (1- (length isearch-lazy-highlight-last-string))) - (window-group-start)))))) + (success nil)) ;; Use a loop like in `isearch-search'. (while retry - (setq success (isearch-search-string - isearch-lazy-highlight-last-string bound t)) + (setq success (isearch-search-string string bound t)) ;; Clear RETRY unless the search predicate says ;; to skip this search hit. (if (or (not success) @@ -3312,6 +3332,20 @@ isearch-lazy-highlight-search success) (error nil))) +(defvar isearch-lazy-highlight-match-function #'isearch-lazy-highlight-match + "Function that highlights the found match. +The function accepts two arguments: the beginning and the end of the match.") + +(defun isearch-lazy-highlight-match (mb me) + (let ((ov (make-overlay mb me))) + (push ov isearch-lazy-highlight-overlays) + ;; 1000 is higher than ediff's 100+, + ;; but lower than isearch main overlay's 1001 + (overlay-put ov 'priority 1000) + (overlay-put ov 'face 'lazy-highlight) + (unless (eq isearch-lazy-highlight 'all-windows) + (overlay-put ov 'window (selected-window))))) + (defun isearch-lazy-highlight-start () "Start a new lazy-highlight updating loop." (lazy-highlight-cleanup t) ;remove old overlays @@ -3321,19 +3355,32 @@ isearch-lazy-highlight-update "Update highlighting of other matches for current search." (let ((max lazy-highlight-max-at-a-time) (looping t) - nomore) + nomore window-start window-end) (with-local-quit (save-selected-window (if (and (window-live-p isearch-lazy-highlight-window) (not (memq (selected-window) isearch-lazy-highlight-window-group))) (select-window isearch-lazy-highlight-window)) + (setq window-start (window-group-start)) + (setq window-end (window-group-end)) (save-excursion (save-match-data (goto-char (if isearch-lazy-highlight-forward isearch-lazy-highlight-end isearch-lazy-highlight-start)) (while looping - (let ((found (isearch-lazy-highlight-search))) + (let* ((bound (if isearch-lazy-highlight-forward + (min (or isearch-lazy-highlight-end-limit (point-max)) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-start + window-end)) + (max (or isearch-lazy-highlight-start-limit (point-min)) + (if isearch-lazy-highlight-wrapped + isearch-lazy-highlight-end + window-start)))) + (found (isearch-lazy-highlight-search + isearch-lazy-highlight-last-string + bound))) (when max (setq max (1- max)) (if (<= max 0) @@ -3345,24 +3392,16 @@ isearch-lazy-highlight-update (if isearch-lazy-highlight-forward (if (= mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-start - (window-group-end))) + window-end)) (setq found nil) (forward-char 1)) (if (= mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end - (window-group-start))) + window-start)) (setq found nil) (forward-char -1))) - ;; non-zero-length match - (let ((ov (make-overlay mb me))) - (push ov isearch-lazy-highlight-overlays) - ;; 1000 is higher than ediff's 100+, - ;; but lower than isearch main overlay's 1001 - (overlay-put ov 'priority 1000) - (overlay-put ov 'face 'lazy-highlight) - (unless (eq isearch-lazy-highlight 'all-windows) - (overlay-put ov 'window (selected-window))))) + (funcall isearch-lazy-highlight-match-function mb me)) ;; Remember the current position of point for ;; the next call of `isearch-lazy-highlight-update' ;; when `lazy-highlight-max-at-a-time' is too small. @@ -3378,17 +3417,83 @@ isearch-lazy-highlight-update (setq isearch-lazy-highlight-wrapped t) (if isearch-lazy-highlight-forward (progn - (setq isearch-lazy-highlight-end (window-group-start)) + (setq isearch-lazy-highlight-end window-start) (goto-char (max (or isearch-lazy-highlight-start-limit (point-min)) - (window-group-start)))) - (setq isearch-lazy-highlight-start (window-group-end)) + window-start))) + (setq isearch-lazy-highlight-start window-end) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) - (window-group-end)))))))) - (unless nomore + window-end))))))) + (if nomore + (when isearch-lazy-highlight-buffer-p + (if isearch-lazy-highlight-forward + (setq isearch-lazy-highlight-end (point-min)) + (setq isearch-lazy-highlight-start (point-max))) + (run-at-time lazy-highlight-interval nil + 'isearch-lazy-highlight-buffer-update)) (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil 'isearch-lazy-highlight-update))))))))) +(defun isearch-lazy-highlight-buffer-update () + "Update highlighting of other matches in the whole buffer." + (let ((max lazy-highlight-buffer-max-at-a-time) + (looping t) + nomore window-start window-end) + (with-local-quit + (save-selected-window + (if (and (window-live-p isearch-lazy-highlight-window) + (not (memq (selected-window) isearch-lazy-highlight-window-group))) + (select-window isearch-lazy-highlight-window)) + (setq window-start (window-group-start)) + (setq window-end (window-group-end)) + (save-excursion + (save-match-data + (goto-char (if isearch-lazy-highlight-forward + isearch-lazy-highlight-end + isearch-lazy-highlight-start)) + (while looping + (let* ((bound (if isearch-lazy-highlight-forward + (or isearch-lazy-highlight-end-limit (point-max)) + (or isearch-lazy-highlight-start-limit (point-min)))) + (found (isearch-lazy-highlight-search + isearch-lazy-highlight-last-string + bound))) + (when max + (setq max (1- max)) + (if (<= max 0) + (setq looping nil))) + (if found + (let ((mb (match-beginning 0)) + (me (match-end 0))) + (if (= mb me) ;zero-length match + (if isearch-lazy-highlight-forward + (if (= mb (point-max)) + (setq found nil) + (forward-char 1)) + (if (= mb (point-min)) + (setq found nil) + (forward-char -1))) + ;; Already highlighted by isearch-lazy-highlight-update + (unless (or (and (>= mb window-start) (<= me window-end)) + (not isearch-lazy-highlight-buffer-p)) + ;; non-zero-length match + (funcall isearch-lazy-highlight-match-function mb me))) + ;; Remember the current position of point for + ;; the next call of `isearch-lazy-highlight-update' + ;; when `lazy-highlight-buffer-max-at-a-time' is too small. + (if isearch-lazy-highlight-forward + (setq isearch-lazy-highlight-end (point)) + (setq isearch-lazy-highlight-start (point))))) + + ;; not found or zero-length match at the search bound + (if (not found) + (setq looping nil + nomore t)))) + (unless nomore + (setq isearch-lazy-highlight-timer + (run-at-time lazy-highlight-interval nil + 'isearch-lazy-highlight-buffer-update))))))))) + (defun isearch-resume (string regexp word forward message case-fold) "Resume an incremental search. STRING is the string or regexp searched for. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 24 20:28:55 2018 Received: (at 29360) by debbugs.gnu.org; 25 Oct 2018 00:28:55 +0000 Received: from localhost ([127.0.0.1]:41036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFTWA-0002fQ-Qc for submit@debbugs.gnu.org; Wed, 24 Oct 2018 20:28:54 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:42134) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFTW9-0002f9-1u for 29360@debbugs.gnu.org; Wed, 24 Oct 2018 20:28:53 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9P0OaO0066445; Thu, 25 Oct 2018 00:28:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Mj1Vd0I9Q6Gm/YbBzlQ6DSBm3b7h2ZPj0MwqOXqcAZU=; b=Csn/xnmzU3QiRzrZz2T+Bhu4gA7wTi6DFzie3wbvLUfUQYEQjdI8DFwybX+AIPNRahTi zMiG2qT3bVBS8f3glg2DI+jarH09hNXXhqo/TOtANd4OMuRyf+YaKaD37hPcLvpUkC+R 2rfCzRi/vOtHiQmE8WRXOAJVtLxqGskCT0UxlcCyDOpWx7PW+H9yOdPhQ2tc5vtldreM 2IANhh8vmAox2hFLXmCeITO4Qyxs16S4IEDFKDrAcFMAlo++8GVYPdbwRGvnOfC6q5Dr Xlw1eDG17tjPwgHFVaQFs7IGVLgF86+ShJ/K5E9lvSMeRDSaN7wum57teXzz0E1DDsje WQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2n7w0qxjsy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 00:28:47 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9P0Sf70021078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 00:28:41 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9P0SfP4020881; Thu, 25 Oct 2018 00:28:41 GMT MIME-Version: 1.0 Message-ID: <5e7994d1-68a8-44ea-98ba-4dfa79b9bb8c@default> Date: Wed, 24 Oct 2018 17:28:40 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> <87efcguxnm.fsf@mail.linkov.net> <3818ac4c-6564-4439-9fb5-c84791f43f7a@default> <87sh0vaqjm.fsf@mail.linkov.net> In-Reply-To: <87sh0vaqjm.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9056 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=428 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250002 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > Absolutely. Like with any similar interaction in > > Emacs the delay before starting should be a user > > option. Users are different, and user machines etc. > > are different. >=20 > You are right, with a small delay lazy-highlighting is responsive. >=20 > In the attached patch I also added a separate variable that you asked for > programmatic use, changed text to "currently visible on the screen" and > mentioned lazy-highlight-cleanup. >=20 > The patch is extensively tested for various scenarios: Super. Thanks for working on this. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 27 16:29:03 2018 Received: (at 29360) by debbugs.gnu.org; 27 Oct 2018 20:29:04 +0000 Received: from localhost ([127.0.0.1]:45810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGVCg-0000Kb-30 for submit@debbugs.gnu.org; Sat, 27 Oct 2018 16:29:03 -0400 Received: from common.maple.relay.mailchannels.net ([23.83.214.38]:6725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGVCe-0000KK-7p; Sat, 27 Oct 2018 16:29:00 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C591F425FE; Sat, 27 Oct 2018 20:28:58 +0000 (UTC) Received: from pdx1-sub0-mail-a3.g.dreamhost.com (unknown [100.96.26.166]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8C8A9426A7; Sat, 27 Oct 2018 20:28:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a3.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Sat, 27 Oct 2018 20:28:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Ruddy-Squirrel: 2fd7d49a1d6c3a16_1540672138682_594487288 X-MC-Loop-Signature: 1540672138681:3052420898 X-MC-Ingress-Time: 1540672138681 Received: from pdx1-sub0-mail-a3.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTP id 465827F694; Sat, 27 Oct 2018 13:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=tKWD7ESnDBkwgy1fdIMHIHBudEI=; b= bZ4c3LNp10eb6460mAlFWI88/jL2+iHZN4ZDRmO9uV8jdJHyCFsEUdOViJ3l2cNk fuoLF/5vcilwXia0bf0Sy16h+1W54BrYiLHeo9np/9S9N1lJgGkGkOqtkYddWwc5 tJGmZcmvZapSGgtAaRHrCPptNawqTAVqzNErdA7L6Zg= Received: from mail.jurta.org (m91-129-105-154.cust.tele2.ee [91.129.105.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTPSA id C2BF27F68E; Sat, 27 Oct 2018 13:28:56 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a3 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> <875zxwjlke.fsf@mail.linkov.net> <87woqbglvb.fsf@mail.linkov.net> <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> <87efcguxnm.fsf@mail.linkov.net> <3818ac4c-6564-4439-9fb5-c84791f43f7a@default> <87sh0vaqjm.fsf@mail.linkov.net> <5e7994d1-68a8-44ea-98ba-4dfa79b9bb8c@default> Date: Sat, 27 Oct 2018 23:28:18 +0300 In-Reply-To: <5e7994d1-68a8-44ea-98ba-4dfa79b9bb8c@default> (Drew Adams's message of "Wed, 24 Oct 2018 17:28:40 -0700 (PDT)") Message-ID: <87zhuz9lst.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheeggdduheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdehrdduheegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddthedrudehgedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 29360 fixed close 29360 27.1 thanks >> In the attached patch I also added a separate variable that you asked for >> programmatic use, changed text to "currently visible on the screen" and >> mentioned lazy-highlight-cleanup. >> >> The patch is extensively tested for various scenarios: > > Super. Thanks for working on this. Installed in 3dd16a89bf. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 27 20:35:14 2018 Received: (at 29360) by debbugs.gnu.org; 28 Oct 2018 00:35:14 +0000 Received: from localhost ([127.0.0.1]:46089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGZ2w-00086K-3P for submit@debbugs.gnu.org; Sat, 27 Oct 2018 20:35:14 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:59106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGZ2t-000862-Vs for 29360@debbugs.gnu.org; Sat, 27 Oct 2018 20:35:12 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9S0Z5OW026508; Sun, 28 Oct 2018 00:35:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=tUOzGCGevjeBWw4cEuISfTtJG6X5HBvpXX8bjpolMxk=; b=N13hbb/HNrT2av6hd9LpSII+G7hwwwsXawxp3NGt98Ne57WCn8hUCw4HNYd8Ud/yV0Jw zwew41/YNn8Qf8uafsRFCOe/qcRRFtOYO/QcOkBMltl5frAyBdYB/V0j0vOTETUTiGfB y1Mp7xAdCDR21kro6CTdeMVPzoaTgFyh4QoqIqBUjNq5WQ2RvVd2+xjXIz+4OcCJX1Qp T8b3ug4tVOf4IQV+mfwEP6rXXUPAUXeAyelwbUeGc9uWN0M6LJJZrfuAWIUT+Z4Rq+r4 wkdA4PKkHxgD0DPWKB8rxAWDZnQQvWMDgn24695d2VRCrIPuYj40MNZMzps84hyWcHcl mg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2ncfet9daw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Oct 2018 00:35:05 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9S0Z5lw013043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Oct 2018 00:35:05 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9S0Z4XX012206; Sun, 28 Oct 2018 00:35:05 GMT MIME-Version: 1.0 Message-ID: <72ae3efe-0aa6-430e-ba99-2d8bc47d3a34@default> Date: Sat, 27 Oct 2018 17:35:03 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29321: Isearch hit count References: <87o9bfqfc3.fsf@mail.linkov.net> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9059 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=663 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810280003 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Moving this back to bug #29360... > > > Juri: Adapting your patch to my code, I notice that it uses > > > `isearch-lazy-highlight-buffer' instead of > > > `isearch-lazy-highlight-buffer-p' now. Did you intend that > > > change back to using the option in those occurrences? > > > > More exactly, it seems like you use a mix now of > > `isearch-lazy-highlight-buffer' and `lazy-highlight-buffer' > > (no `isearch-'), the latter of which is not in your previous > > patches at all (for bug #29360). > > > > Please advise. What replaced what exactly, in this regard? >=20 > I guess that since your patch to the bug thread you just renamed > isearch-lazy-highlight-buffer to lazy-highlight-buffer and you > renamed isearch-lazy-highlight-buffer-p to > isearch-lazy-highlight-buffer. >=20 > If something other or more than that was involved, please let me know. Hm. Seems like you also removed `isearch-lazy-highlight-match-function', which was present in your patches. Why is that? I know that you you used only `isearch-lazy-highlight-match' as the value, but did you have something else in mind for it? Can I expect that you will add back that variable? From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 28 18:40:42 2018 Received: (at 29360) by debbugs.gnu.org; 28 Oct 2018 22:40:42 +0000 Received: from localhost ([127.0.0.1]:49425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGtjd-0000kz-UL for submit@debbugs.gnu.org; Sun, 28 Oct 2018 18:40:42 -0400 Received: from fossa.birch.relay.mailchannels.net ([23.83.209.62]:46249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGtjb-0000ko-Sl for 29360@debbugs.gnu.org; Sun, 28 Oct 2018 18:40:40 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 065CC122876; Sun, 28 Oct 2018 22:40:38 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BF7181228F4; Sun, 28 Oct 2018 22:40:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a9.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Sun, 28 Oct 2018 22:40:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Glossy-Stupid: 178ef0f63c2687ff_1540766437856_3655494661 X-MC-Loop-Signature: 1540766437856:1575721800 X-MC-Ingress-Time: 1540766437856 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 88C597F7BC; Sun, 28 Oct 2018 15:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=F3OhYOdU6+dQHPAZ4r7BwNHIy1Y=; b= nhVADwOgOSOnqQje1fN0S3HBU8/8boZOU7q2BgKSYKEN8QAqjkEP0e6KHCsppNYR Z9jIkGCp4iKv0TOQg3Q14iAajHPUBeI/wSJ90f2bpLquI183x+EJig0TBPW3nDj9 BRSg6M46NtGLhiyOwF6CoQc9tqUoTEO5CeNc5xEhKiE= Received: from mail.jurta.org (m91-129-105-154.cust.tele2.ee [91.129.105.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 9B19A7F7B7; Sun, 28 Oct 2018 15:40:34 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a9 From: Juri Linkov To: Drew Adams Subject: Re: bug#29360: Add full-buffer choice for `isearch-lazy-highlight' Organization: LINKOV.NET References: <87o9bfqfc3.fsf@mail.linkov.net> <72ae3efe-0aa6-430e-ba99-2d8bc47d3a34@default> Date: Mon, 29 Oct 2018 00:34:32 +0200 In-Reply-To: <72ae3efe-0aa6-430e-ba99-2d8bc47d3a34@default> (Drew Adams's message of "Sat, 27 Oct 2018 17:35:03 -0700 (PDT)") Message-ID: <874ld5g233.fsf_-_@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrheeigdduieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdehrdduheegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddthedrudehgedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> I guess that since your patch to the bug thread you just renamed >> isearch-lazy-highlight-buffer to lazy-highlight-buffer and you >> renamed isearch-lazy-highlight-buffer-p to >> isearch-lazy-highlight-buffer. I renamed isearch-lazy-highlight-buffer to lazy-highlight-buffer after realizing that the same feature might be needed also in query-replace, therefore generalized it by removing the prefix isearch-. > Hm. Seems like you also removed `isearch-lazy-highlight-match-function', > which was present in your patches. Why is that? I know that you > you used only `isearch-lazy-highlight-match' as the value, but did > you have something else in mind for it? Can I expect that you will > add back that variable? I strive to keep my changes as minimal as possible to not introduce unused variables. However, if you can demonstrate a real need we could add it when necessary. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 28 18:57:33 2018 Received: (at 29360) by debbugs.gnu.org; 28 Oct 2018 22:57:33 +0000 Received: from localhost ([127.0.0.1]:49438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGtzx-00018R-7W for submit@debbugs.gnu.org; Sun, 28 Oct 2018 18:57:33 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:44606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGtzu-000186-OL for 29360@debbugs.gnu.org; Sun, 28 Oct 2018 18:57:31 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9SMsHwX017397; Sun, 28 Oct 2018 22:57:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=uoGf6j1OegyHd/IDf3udPVQtFqwCKdJ4scFgoVLrOao=; b=Sqh+YdrrcnVOPu+OVT5p5kd532aJHYzVJQC89ZI9Cx32vfFIXfuhgu/0Q8KmrngiJG0s KvEIlN5NMRLUp7kijqxQK58obRjBIli70f75KNaljIBxqJHgN62evH8Chqsqa/Qt+DGk SC61CNVMUiQKdivrxjiEN6zNf4z3lYSVeHKGXPHZ9xcnc6APORgYrLRsLNUKJNTTBkUF yTleziKFvVYP/9IGyeazZR8UzLoeqQevFn4V7PFoONBX0lF/Cqy2wVo/uXRvtu2u1K6Z Dk9NtGKI9wBPC2YQ8ug/kOzYcw5dJNETQz2MrUvNg7alKGog8kl1Weq5vKzhkJCCoLFw Tw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2ncfetatpq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Oct 2018 22:57:24 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9SMvNlY027678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Oct 2018 22:57:23 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9SMvMeU009397; Sun, 28 Oct 2018 22:57:22 GMT MIME-Version: 1.0 Message-ID: Date: Sun, 28 Oct 2018 15:57:21 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#29360: Add full-buffer choice for `isearch-lazy-highlight' References: <87o9bfqfc3.fsf@mail.linkov.net> <72ae3efe-0aa6-430e-ba99-2d8bc47d3a34@default> <874ld5g233.fsf_-_@mail.linkov.net> In-Reply-To: <874ld5g233.fsf_-_@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9060 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=838 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810280213 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 29360 Cc: 29360@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> I guess that since your patch to the bug thread you just renamed > >> isearch-lazy-highlight-buffer to lazy-highlight-buffer and you > >> renamed isearch-lazy-highlight-buffer-p to > >> isearch-lazy-highlight-buffer. >=20 > I renamed isearch-lazy-highlight-buffer to lazy-highlight-buffer > after realizing that the same feature might be needed also in > query-replace, therefore generalized it by removing the prefix > isearch-. Yes, I figured that. > > Hm. Seems like you also removed `isearch-lazy-highlight-match- > function', > > which was present in your patches. Why is that? I know that you > > you used only `isearch-lazy-highlight-match' as the value, but did > > you have something else in mind for it? Can I expect that you will > > add back that variable? >=20 > I strive to keep my changes as minimal as possible to not introduce > unused variables. However, if you can demonstrate a real need > we could add it when necessary. I'm OK with all that you've done. I may leave the variable in my code, probably only out of laziness to remove it. ;-) Thanks for your work on this. From unknown Fri Jun 20 07:23:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 26 Nov 2018 12:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator