From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 19 09:37:19 2015 Received: (at submit) by debbugs.gnu.org; 19 Jul 2015 13:37:19 +0000 Received: from localhost ([127.0.0.1]:53625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZGomL-0000Od-VF for submit@debbugs.gnu.org; Sun, 19 Jul 2015 09:37:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49362) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZGomH-0000OM-UO for submit@debbugs.gnu.org; Sun, 19 Jul 2015 09:37:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZGomB-0001fF-SK for submit@debbugs.gnu.org; Sun, 19 Jul 2015 09:37:08 -0400 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]:56695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGomB-0001fA-PD for submit@debbugs.gnu.org; Sun, 19 Jul 2015 09:37:07 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGomB-00022J-0o for bug-gnu-emacs@gnu.org; Sun, 19 Jul 2015 09:37:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZGom5-0001eF-Tv for bug-gnu-emacs@gnu.org; Sun, 19 Jul 2015 09:37:06 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:23384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGom5-0001dJ-NW for bug-gnu-emacs@gnu.org; Sun, 19 Jul 2015 09:37:01 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6JDb0EX006371 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 19 Jul 2015 13:37:00 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t6JDaxw5021843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 19 Jul 2015 13:37:00 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6JDawp1022985 for ; Sun, 19 Jul 2015 13:36:59 GMT MIME-Version: 1.0 Message-ID: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default> Date: Sun, 19 Jul 2015 06:36:55 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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: -4.0 (----) 1. emacs -Q 2. Visit a file - anything other than a tiny one will do. 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil and set `lazy-max-at-a-time' to nil. 4. Search once for a simple string that occurs multiple times throughout the buffer - e.g., `C-s the RET`. 5. Scroll down to see that the matches were not highlighted throughout the buffer. `lazy-highlight-max-at-a-time' does not work as advertised. In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-07-03 on LEG570 Bzr revision: 2b848fadd51e805b2f46da64c5958ea7f009048a Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --host=3Di686-pc-mingw32 --enable-checking=3Dyes,glyphs' From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 27 16:30:08 2015 Received: (at 21092) by debbugs.gnu.org; 27 Aug 2015 20:30:08 +0000 Received: from localhost ([127.0.0.1]:40616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV3oE-0003sw-P9 for submit@debbugs.gnu.org; Thu, 27 Aug 2015 16:30:07 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25318) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV3o9-0003rz-QM for 21092@debbugs.gnu.org; Thu, 27 Aug 2015 16:30:03 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7RKU0Yx000325 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <21092@debbugs.gnu.org>; Thu, 27 Aug 2015 20:30:00 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7RKTxET014297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <21092@debbugs.gnu.org>; Thu, 27 Aug 2015 20:29:59 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7RKTxed004605 for <21092@debbugs.gnu.org>; Thu, 27 Aug 2015 20:29:59 GMT MIME-Version: 1.0 Message-ID: <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default> Date: Thu, 27 Aug 2015 13:29:58 -0700 (PDT) From: Drew Adams To: 21092@debbugs.gnu.org Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default> In-Reply-To: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (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: -3.7 (---) X-Debbugs-Envelope-To: 21092 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > 1. emacs -Q > 2. Visit a file - anything other than a tiny one will do. > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil > and set `lazy-max-at-a-time' to nil. > 4. Search once for a simple string that occurs multiple times throughout > the buffer - e.g., `C-s the RET`. > 5. Scroll down to see that the matches were not highlighted throughout > the buffer. `lazy-highlight-max-at-a-time' does not work as > advertised. [Typo in step 3: `lazy-max-at-a-time' should be `lazy-highlight-max-at-a-time' (as in step 5).] It would be great to hear back about this. Is this a bug or am I misunderstanding something? The doc seems to say that you can expect that all search hits will be highlighted when the value of `lazy-highlight-max-at-a-time' is nil: "A value of nil means highlight all matches." Even the Customize value menu text says this. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 04:57:29 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 08:57:29 +0000 Received: from localhost ([127.0.0.1]:40791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFTV-0001Rv-2a for submit@debbugs.gnu.org; Fri, 28 Aug 2015 04:57:29 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:57536) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVFTS-0001Rm-Hw for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 04:57:27 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NTS00O00BH6HY00@mtaout29.012.net.il> for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 11:57:37 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS00GBFBK1EH80@mtaout29.012.net.il>; Fri, 28 Aug 2015 11:57:37 +0300 (IDT) Date: Fri, 28 Aug 2015 11:57:27 +0300 From: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work In-reply-to: <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83lhcv4wp4.fsf@gnu.org> References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default> <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > Date: Thu, 27 Aug 2015 13:29:58 -0700 (PDT) > From: Drew Adams > > > 1. emacs -Q > > 2. Visit a file - anything other than a tiny one will do. > > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil > > and set `lazy-max-at-a-time' to nil. > > 4. Search once for a simple string that occurs multiple times throughout > > the buffer - e.g., `C-s the RET`. > > 5. Scroll down to see that the matches were not highlighted throughout > > the buffer. `lazy-highlight-max-at-a-time' does not work as > > advertised. > > [Typo in step 3: `lazy-max-at-a-time' should be > `lazy-highlight-max-at-a-time' (as in step 5).] > > It would be great to hear back about this. Is this a bug or am I > misunderstanding something? What do you mean by "scroll down" in step 5 above? Scroll down how? Scrolling (as any other command that exits I-search) removes all highlighting, at least by default. And "all matches" in the variable's doc string means "all matches shown on the screen", as the display engine never does anything beyond the displayed portion (that's a simplification, but it will do for the purposes of this discussion). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 11:19:42 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 15:19:42 +0000 Received: from localhost ([127.0.0.1]:41583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLRO-0003bJ-0W for submit@debbugs.gnu.org; Fri, 28 Aug 2015 11:19:42 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:40239) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLRL-0003bA-A4 for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 11:19:40 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SFJbDo009733 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 15:19:38 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7SFJbPs024985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 15:19:37 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7SFJavH024590; Fri, 28 Aug 2015 15:19:37 GMT MIME-Version: 1.0 Message-ID: <56e13714-27a7-47f9-93df-299b4a25457d@default> Date: Fri, 28 Aug 2015 08:19:35 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <<7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <<83lhcv4wp4.fsf@gnu.org>> In-Reply-To: <<83lhcv4wp4.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > > > 1. emacs -Q > > > 2. Visit a file - anything other than a tiny one will do. > > > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil > > > and set `lazy-highlight-max-at-a-time' to nil. > > > 4. Search once for a simple string that occurs multiple times through= out > > > the buffer - e.g., `C-s the RET`. > > > 5. Scroll down to see that the matches were not highlighted throughou= t > > > the buffer. `lazy-highlight-max-at-a-time' does not work as > > > advertised. >=20 > What do you mean by "scroll down" in step 5 above? Scroll down how? C-v or whatever. (Yes, this will exit Isearch,) > Scrolling (as any other command that exits I-search) removes all > highlighting, at least by default. No, it does not. Not if `lazy-highlight-cleanup' is nil - see step 3. That's the point of that option, and of this bug report. > And "all matches" in the > variable's doc string means "all matches shown on the screen", How could that be? What's the point of the option value of nil - or even a large value - in that case? And why would we bother to warn that a large (let alone a nil) value can make things slow, if highlighting is always limited to what is visible "on the screen"? How big a screen would someone have to have, to make any consideration of performance important, if nil is _supposed_ to highlight only all matches "on the screen"? Where do you get your interpretation of "all matches"? From the display-engine code, I guess, but certainly not from the doc or the Customize UI, which says just "All". All matches means all matches; it does not mean all matches that fit some unmentioned criterion. > as the display engine never does anything beyond the displayed > portion (that's a simplification, but it will do for the purposes > of this discussion). That description of the display-engine _implementation_, which I don't doubt, does not jibe with the description of the option. And as the description is quite deliberate about the possibilities and behavior of both a LARGE value and a nil value, and about the consequent risks to performance, it would seem that the _design_ of this feature does not fit the display-engine implementation. Am I missing something else? What's the point of such a design (and its consequent doc), if it could _never be realized_ because of display-engine limitations? (I don't doubt the display-engine design or implementation. The question is about how this design could possibly work, given the display engine as you say it is.) Something else puzzles me. I did not have the impression that there was such a hard-and-fast display limitation. Am I mistaken that we have no problem forcing the display engine to font-lock fontify a whole buffer, regardless of size? If that is possible (I am thinking it is possible, but I could be wrong) then why would it not also be possible to put lazy-highlight highlighting on a whole buffer, regardless of size? And I can call a homemade function that highlights stuff throughout a LARGE buffer, whether using font-lock or otherwise. No problem, AFAICS. Wrt the actual behavior I see: a nil value seems, indeed to have no effect beyond the text that has already been shown. That's really too bad. (And lazy highlighting, beyond just highlighting, also computes all search matches, which can be useful. But perhaps you will say that it computes only all matches on the screen?) I do hope that someone takes a close look at this and you don't just dismiss it. AFAICT, it is possible to highlight text throughout a buffer, even a VERY large one, and using either overlays or text properties. IOW, I don't understand - I don't think I see the display-engine limitation you seem to be saying is in place. IIUC, a lot has changed since lazy highlighting and these options were first introduced - jit-lock, etc. Perhaps this worked at one time, and a regression was introduced since then? (No, I don't see that myself - the same bug is in Emacs 22.3.) Or are you absolutely convinced that this could never have worked, because of the way the display engine works? If so then I'm quite disappointed, but in that case please at least correct the doc and the Customize UI, to make clear that the value (numeric or nil) has no effect beyond what is/has been shown on the screen - that it is not at all about highlighting "all matches". And given that Lisp code apparently _can_ highlight a whole, large buffer (AFAICT), if you have any tips on how I might make this work, myself, for Isearch lazy highlighting, please pass them along. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 11:46:43 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 15:46:43 +0000 Received: from localhost ([127.0.0.1]:41588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLrW-0004Ep-Tc for submit@debbugs.gnu.org; Fri, 28 Aug 2015 11:46:43 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54275) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLrU-0004Ef-23 for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 11:46:41 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTS00900UDCAS00@a-mtaout22.012.net.il> for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 18:46:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS009P3UHP8I20@a-mtaout22.012.net.il>; Fri, 28 Aug 2015 18:46:38 +0300 (IDT) Date: Fri, 28 Aug 2015 18:46:41 +0300 From: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work In-reply-to: <56e13714-27a7-47f9-93df-299b4a25457d@default> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83wpwf2z6m.fsf@gnu.org> References: <56e13714-27a7-47f9-93df-299b4a25457d@default> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > Date: Fri, 28 Aug 2015 08:19:35 -0700 (PDT) > From: Drew Adams > Cc: 21092@debbugs.gnu.org > > > > > 1. emacs -Q > > > > 2. Visit a file - anything other than a tiny one will do. > > > > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil > > > > and set `lazy-highlight-max-at-a-time' to nil. > > > > 4. Search once for a simple string that occurs multiple times throughout > > > > the buffer - e.g., `C-s the RET`. > > > > 5. Scroll down to see that the matches were not highlighted throughout > > > > the buffer. `lazy-highlight-max-at-a-time' does not work as > > > > advertised. > > > > What do you mean by "scroll down" in step 5 above? Scroll down how? > > C-v or whatever. (Yes, this will exit Isearch,) > > > Scrolling (as any other command that exits I-search) removes all > > highlighting, at least by default. > > No, it does not. Not if `lazy-highlight-cleanup' is nil - see step 3. Missed that, sorry. > > And "all matches" in the > > variable's doc string means "all matches shown on the screen", > > How could that be? I don't know, but that's what I clearly see. > IIUC, a lot has changed since lazy highlighting and these options > were first introduced - jit-lock, etc. Perhaps this worked at one > time, and a regression was introduced since then? (No, I don't see > that myself - the same bug is in Emacs 22.3.) Do you see any previous version of Emacs where it worked as you expect? I don't. I will now shut up and let people who actually know something about isearch.el talk. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 11:59:42 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 15:59:42 +0000 Received: from localhost ([127.0.0.1]:41597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVM45-0004Wc-Nw for submit@debbugs.gnu.org; Fri, 28 Aug 2015 11:59:42 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:34854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVM43-0004WU-RG for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 11:59:40 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SFxbwJ002242 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 15:59:38 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7SFxauA013781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 15:59:36 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7SFxaB7028864; Fri, 28 Aug 2015 15:59:36 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 28 Aug 2015 08:59:34 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<83wpwf2z6m.fsf@gnu.org>> In-Reply-To: <<83wpwf2z6m.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > > IIUC, a lot has changed since lazy highlighting and these options > > were first introduced - jit-lock, etc. Perhaps this worked at one > > time, and a regression was introduced since then? (No, I don't see > > that myself - the same bug is in Emacs 22.3.) >=20 > Do you see any previous version of Emacs where it worked as you > expect? I don't. As I said, no, I don't either. I am also guessing that few people have ever used a nil value of `lazy-highlight-cleanup'. I have it on/off as an Isearch toggle key now, and with that easy access I find it quite useful. > I will now shut up and let people who actually know something about > isearch.el talk. OK, but I am interested in the general question of whether the display engine precludes highlighting more than what is "on screen". Could you speak to that? What am I missing? AFAICT, it is possible to highlight, with either text properties or overlays, a very large buffer. Do you agree? If so, why should that not be possible for lazy highlighting also, because of a display-engine limitation/design? IOW, I don't understand how I can highlight a large buffer but Isearch lazy-highlight cannot do this because of the display engine. This is not a rhetorical argument. I would like to understand whether it is possible to fix this bug, to let users control the scope of lazy highlighting beyond what is "on the screen". Perhaps neither you nor I "know something about isearch.el", but you certainly know something about the display engine. A little help understanding this limitation, please. Thx. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 12:03:46 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 16:03:46 +0000 Received: from localhost ([127.0.0.1]:41601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVM81-0004dg-Vh for submit@debbugs.gnu.org; Fri, 28 Aug 2015 12:03:46 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:32973) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVM7z-0004dX-QG for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 12:03:44 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTS00N00V68C400@mtaout28.012.net.il> for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 19:03:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTS00B5KV9Y43E0@mtaout28.012.net.il>; Fri, 28 Aug 2015 19:03:34 +0300 (IDT) Date: Fri, 28 Aug 2015 19:03:45 +0300 From: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83twrj2ye6.fsf@gnu.org> References: <56e13714-27a7-47f9-93df-299b4a25457d@default> <83wpwf2z6m.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > Date: Fri, 28 Aug 2015 08:59:34 -0700 (PDT) > From: Drew Adams > Cc: 21092@debbugs.gnu.org > > I am interested in the general question of whether the > display engine precludes highlighting more than what is "on screen". You can, of course, put the overlays or properties with some face on the entire buffer. So no, the display engine doesn't preclude that. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 12:15:28 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 16:15:28 +0000 Received: from localhost ([127.0.0.1]:41605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMJM-0004u3-2j for submit@debbugs.gnu.org; Fri, 28 Aug 2015 12:15:28 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:24745) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMJJ-0004tv-Nm for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 12:15:26 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SGFNoE005457 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 16:15:24 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGFN8r022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 16:15:23 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGFMVt005291; Fri, 28 Aug 2015 16:15:23 GMT MIME-Version: 1.0 Message-ID: <9948c583-9ab8-4c2e-a5fd-82df1e98e5c1@default> Date: Fri, 28 Aug 2015 09:15:20 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<83wpwf2z6m.fsf@gnu.org>> <> <<83twrj2ye6.fsf@gnu.org>> In-Reply-To: <<83twrj2ye6.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (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: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > > I am interested in the general question of whether the > > display engine precludes highlighting more than what is "on screen". >=20 > You can, of course, put the overlays or properties with some face on > the entire buffer. So no, the display engine doesn't preclude that. OK, great to hear. So this is a real Isearch bug, and there is a possibility for it to be fixed. Hopefully someone knowledgable will contribute to a solution. I can try to help, but it would be great if Juri or someone else who understands the code well could lead. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 12:44:39 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 16:44:39 +0000 Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMlb-0005aY-20 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 12:44:39 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:29523) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMlY-0005aP-Ki for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 12:44:37 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SGiYj9030178 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 16:44:35 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGiYY1007093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 16:44:34 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGiY7T021195; Fri, 28 Aug 2015 16:44:34 GMT MIME-Version: 1.0 Message-ID: <31c8bd13-e53c-41b8-ae36-cbbb13d2001d@default> Date: Fri, 28 Aug 2015 09:44:32 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<83wpwf2z6m.fsf@gnu.org>> <> <<83twrj2ye6.fsf@gnu.org>> <9948c583-9ab8-4c2e-a5fd-82df1e98e5c1@default> In-Reply-To: <9948c583-9ab8-4c2e-a5fd-82df1e98e5c1@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > OK, great to hear. So this is a real Isearch bug, and there is a > possibility for it to be fixed. >=20 > Hopefully someone knowledgable will contribute to a solution. > I can try to help, but it would be great if Juri or someone else > who understands the code well could lead. OK, I think I found the problem. I have something working, but will send it in the form of a patch in a while. Essentially, it is the isearch.el code itself that imposes, in a few places, not searching past (window-end) or before (window-start), regardless of the value of `isearch-lazy-highlight-max-at-a-time'. This is what needs to be fixed, to be (point-max) and (point-min) when `isearch-lazy-highlight-max-at-a-time' is nil. A more thoroughgoing fix would take into account a numeric value of `isearch-lazy-highlight-max-at-a-time', but I won't bother with that, for now. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 12:59:26 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 16:59:26 +0000 Received: from localhost ([127.0.0.1]:41621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMzt-0005uv-M7 for submit@debbugs.gnu.org; Fri, 28 Aug 2015 12:59:25 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:18359) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVMzr-0005un-GQ for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 12:59:24 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SGxL8j032414 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 16:59:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGxLWb030245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 16:59:21 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7SGxLdl017842; Fri, 28 Aug 2015 16:59:21 GMT MIME-Version: 1.0 Message-ID: <360259eb-56eb-49d2-9c98-edd0c79fc4d6@default> Date: Fri, 28 Aug 2015 09:59:18 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<83wpwf2z6m.fsf@gnu.org>> <> <<83twrj2ye6.fsf@gnu.org>> <9948c583-9ab8-4c2e-a5fd-82df1e98e5c1@default> <31c8bd13-e53c-41b8-ae36-cbbb13d2001d@default> In-Reply-To: <31c8bd13-e53c-41b8-ae36-cbbb13d2001d@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: multipart/mixed; boundary="__1440781160895310179abhmp0010.oracle.com" X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) --__1440781160895310179abhmp0010.oracle.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > OK, I think I found the problem. I have something working, > but will send it in the form of a patch in a while. >=20 > Essentially, it is the isearch.el code itself that imposes, in > a few places, not searching past (window-end) or before > (window-start), regardless of the value of > `isearch-lazy-highlight-max-at-a-time'. This is what needs to > be fixed, to be (point-max) and (point-min) when > `isearch-lazy-highlight-max-at-a-time' is nil. >=20 > A more thoroughgoing fix would take into account a numeric > value of `isearch-lazy-highlight-max-at-a-time', but I won't > bother with that, for now. Attached is a quick patch that seems to be OK wrt fixing things for a nil value of `isearch-lazy-highlight-max-at-a-time'. Please give it a try. If OK then I will update the doc and defcustom to make clear that (for now) this works only for nil and not for a large value. Feel free to adjust the fix. Or to extend it to also take a numeric value into account. But I will be happy if it is fixed at least for nil. --__1440781160895310179abhmp0010.oracle.com Content-Type: application/octet-stream; name="isearch-2015-08-28.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isearch-2015-08-28.patch" ZGlmZiAtdXcgaXNlYXJjaC5lbCBpc2VhcmNoLXBhdGNoZWQtMjAxNS0wOC0yOC5lbAotLS0gaXNl YXJjaC5lbAkyMDE1LTA4LTI4IDA5OjQ3OjQ1LjQzMTI1MjgwMCAtMDcwMAorKysgaXNlYXJjaC1w YXRjaGVkLTIwMTUtMDgtMjguZWwJMjAxNS0wOC0yOCAwOTo1MTo0MC42ODM3MDg1MDAgLTA3MDAK QEAgLTMwOTIsMTMgKzMwOTIsMTMgQEAKIAkJCQkoKyBpc2VhcmNoLWxhenktaGlnaGxpZ2h0LXN0 YXJ0CiAJCQkJICAgOzsgRXh0ZW5kIGJvdW5kIHRvIG1hdGNoIHdob2xlIHN0cmluZyBhdCBwb2lu dAogCQkJCSAgICgxLSAobGVuZ3RoIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtbGFzdC1zdHJpbmcp KSkKLQkJCSAgICAgICh3aW5kb3ctZW5kKSkpCisJCQkgICAgICAoaWYgbGF6eS1oaWdobGlnaHQt bWF4LWF0LWEtdGltZSAod2luZG93LWVuZCkgKHBvaW50LW1heCkpKSkKIAkJICAgICAobWF4IChv ciBpc2VhcmNoLWxhenktaGlnaGxpZ2h0LXN0YXJ0LWxpbWl0IChwb2ludC1taW4pKQogCQkJICAo aWYgaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC13cmFwcGVkCiAJCQkgICAgICAoLSBpc2VhcmNoLWxh enktaGlnaGxpZ2h0LWVuZAogCQkJCSA7OyBFeHRlbmQgYm91bmQgdG8gbWF0Y2ggd2hvbGUgc3Ry aW5nIGF0IHBvaW50CiAJCQkJICgxLSAobGVuZ3RoIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtbGFz dC1zdHJpbmcpKSkKLQkJCSAgICAod2luZG93LXN0YXJ0KSkpKSkpCisJCQkgICAgKGlmIGxhenkt aGlnaGxpZ2h0LW1heC1hdC1hLXRpbWUgKHdpbmRvdy1zdGFydCkgKHBvaW50LW1heCkpKSkpKSkK IAk7OyBVc2UgYSBsb29wIGxpa2UgaW4gYGlzZWFyY2gtc2VhcmNoJy4KIAkod2hpbGUgcmV0cnkK IAkgIChzZXRxIHN1Y2Nlc3MgKGlzZWFyY2gtc2VhcmNoLXN0cmluZwpAQCAtMzE0MiwxMiArMzE0 MiwxMiBAQAogCQkJICAoaWYgaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC1mb3J3YXJkCiAJCQkgICAg ICAoaWYgKD0gbWIgKGlmIGlzZWFyY2gtbGF6eS1oaWdobGlnaHQtd3JhcHBlZAogCQkJCQkgICAg aXNlYXJjaC1sYXp5LWhpZ2hsaWdodC1zdGFydAotCQkJCQkgICh3aW5kb3ctZW5kKSkpCisJCQkJ CSAgKGlmIG1heCAod2luZG93LWVuZCkgKHBvaW50LW1heCkpKSkKIAkJCQkgIChzZXRxIGZvdW5k IG5pbCkKIAkJCQkoZm9yd2FyZC1jaGFyIDEpKQogCQkJICAgIChpZiAoPSBtYiAoaWYgaXNlYXJj aC1sYXp5LWhpZ2hsaWdodC13cmFwcGVkCiAJCQkJCSAgaXNlYXJjaC1sYXp5LWhpZ2hsaWdodC1l bmQKLQkJCQkJKHdpbmRvdy1zdGFydCkpKQorCQkJCQkoaWYgbWF4ICh3aW5kb3ctc3RhcnQpIChw b2ludC1taW4pKSkpCiAJCQkJKHNldHEgZm91bmQgbmlsKQogCQkJICAgICAgKGZvcndhcmQtY2hh ciAtMSkpKQogCg== --__1440781160895310179abhmp0010.oracle.com-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 17:17:05 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 21:17:05 +0000 Received: from localhost ([127.0.0.1]:41741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVR1F-0006Zh-Cw for submit@debbugs.gnu.org; Fri, 28 Aug 2015 17:17:05 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:58482 helo=homiemail-a21.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVR1D-0006ZZ-50 for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 17:17:03 -0400 Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 3239530008F; Fri, 28 Aug 2015 14:17:02 -0700 (PDT) Received: from localhost.linkov.net (m91-129-114-88.cust.tele2.ee [91.129.114.88]) (Authenticated sender: jurta@jurta.org) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id C1145300079; Fri, 28 Aug 2015 14:17:00 -0700 (PDT) From: Juri Linkov To: Drew Adams Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <83lhcv4wp4.fsf@gnu.org>> <56e13714-27a7-47f9-93df-299b4a25457d@default> Date: Sat, 29 Aug 2015 00:14:30 +0300 In-Reply-To: <56e13714-27a7-47f9-93df-299b4a25457d@default> (Drew Adams's message of "Fri, 28 Aug 2015 08:19:35 -0700 (PDT)") Message-ID: <87si73dsjt.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) > Am I missing something else? Eli is right - lazy-highlight is designed to show matches only on the screen. > please at least correct the doc and the Customize UI, to make clear > that the value (numeric or nil) has no effect beyond what is/has been > shown on the screen - that it is not at all about highlighting "all mat= ches". A fix for the docstring of =E2=80=98lazy-highlight-max-at-a-time=E2=80=99= is to replace =E2=80=9CA value of nil means highlight all matches.=E2=80=9D with =E2=80=9CA value of nil means highlight all matches shown on the screen= .=E2=80=9D > And given that Lisp code apparently _can_ highlight a whole, large > buffer (AFAICT), if you have any tips on how I might make this work, > myself, for Isearch lazy highlighting, please pass them along. To highlight the whole buffer you can use =E2=80=98C-s the M-s h r=E2=80=99 (isearch-highlight-regexp). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 28 17:43:19 2015 Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 21:43:19 +0000 Received: from localhost ([127.0.0.1]:41772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVRQd-0007BS-6b for submit@debbugs.gnu.org; Fri, 28 Aug 2015 17:43:19 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:34193) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVRQa-0007BK-HL for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 17:43:17 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SLhENO021861 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 21:43:15 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7SLhEP1018276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 21:43:14 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7SLhDTq031585; Fri, 28 Aug 2015 21:43:13 GMT MIME-Version: 1.0 Message-ID: Date: Fri, 28 Aug 2015 14:43:11 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <83lhcv4wp4.fsf@gnu.org>> <56e13714-27a7-47f9-93df-299b4a25457d@default> <87si73dsjt.fsf@mail.linkov.net> In-Reply-To: <87si73dsjt.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -3.7 (---) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (---) > Eli is right - lazy-highlight is designed to show matches > only on the screen. No, that is wrong. And that is not what Eli said, in any case. He said that the display engine (not lazy-highlight) is designed to highlight only what is shown on the screen. Lazy highlighting seems pretty clearly to have been designed from the outset with the possibility that you can control how much it highlights, for _performance_ reasons, and that you can, explicitly, choose to highlight everywhere if you want. By default, lazy highlighting does not extend far, and it is removed when you finish searching. But both of these default behaviors are optional, changeable for situations where you want to highlight more and you want to keep the highlighting after searching, respectively. I think Eli was mistaken wrt each of these, but that's not important. =20 > A fix for the docstring of =E2=80=98lazy-highlight-max-at-a-time=E2=80=99= is to replace > =E2=80=9CA value of nil means highlight all matches.=E2=80=9D with > =E2=80=9CA value of nil means highlight all matches shown on the screen= .=E2=80=9D I disagree strongly that this is proper. This is not a doc problem. Clearly the intention of nil `lazy-highlight-max-at-a-time' is to enable lazy highlighting throughout the search space. > > And given that Lisp code apparently _can_ highlight a whole, large > > buffer (AFAICT), if you have any tips on how I might make this work, > > myself, for Isearch lazy highlighting, please pass them along. >=20 > To highlight the whole buffer you can use =E2=80=98C-s the M-s h r=E2=80= =99 > (isearch-highlight-regexp). My request was before I found a fix, and it was to help find a fix for the bug, not to highlight a regexp everywhere. What you mention here is totally unrelated to lazy highlighting, not only in effect but in purpose. I did not ask how to highlight a regexp throughout a buffer. I asked for tips about fixing the bug, so that lazy highlighting could optionally be applied throughout the buffer, as intended by a nil value of =E2=80=98lazy-highlight-max-at-a-time= =E2=80=99. Please see the simple patch I sent, which I think takes care of this. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 29 03:07:44 2015 Received: (at 21092) by debbugs.gnu.org; 29 Aug 2015 07:07:44 +0000 Received: from localhost ([127.0.0.1]:41959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVaEq-0005Zz-4t for submit@debbugs.gnu.org; Sat, 29 Aug 2015 03:07:44 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:49343) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVaEn-0005Zq-4N for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 03:07:42 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTU00G000MOCH00@mtaout28.012.net.il> for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 10:07:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTU00HTC14JDU00@mtaout28.012.net.il>; Sat, 29 Aug 2015 10:07:31 +0300 (IDT) Date: Sat, 29 Aug 2015 10:07:44 +0300 From: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work In-reply-to: X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83pp26373z.fsf@gnu.org> References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default> <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default> <83lhcv4wp4.fsf@gnu.org> <56e13714-27a7-47f9-93df-299b4a25457d@default> <87si73dsjt.fsf@mail.linkov.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > Date: Fri, 28 Aug 2015 14:43:11 -0700 (PDT) > From: Drew Adams > Cc: Eli Zaretskii , 21092@debbugs.gnu.org > > Please see the simple patch I sent, which I think takes care of this. If we are going to extend highlighting beyond the displayed portion of the buffer, then your proposed patch needs more work, IMO. AFAIU, with your patch, setting lazy-highlight-max-at-a-time to, say, 2000, will still limit the highlighting to the displayed portion, which makes little sense to me, as the probability of finding more than 2000 matches in a single window-full is practically zero, and so the user's intent will not be honored (and the doc string will still be misleading). Instead, I suggest to use a special non-nil value, e.g. zero or -1, to indicate a limit to the current window's end, and treat any other value literally, disregarding the window limits. (This will need to be reflected in the documentation, of course.) That special value should IMO be the default. Or maybe introduce a separate predicate option for whether to limit to window start and end. Yes, this would be a backward-incompatible change, but I don't think the difference will matter too much in most use cases, especially with the default value of lazy-highlight-cleanup. Btw, another issue that arises in this regard is whether to highlight beyond the screen only in the direction of the search (which AFAICS is what your proposed patch does) or in both directions, especially when the value of lazy-highlight-max-at-a-time is nil. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 29 10:42:50 2015 Received: (at 21092) by debbugs.gnu.org; 29 Aug 2015 14:42:51 +0000 Received: from localhost ([127.0.0.1]:42194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVhLG-0001NO-D4 for submit@debbugs.gnu.org; Sat, 29 Aug 2015 10:42:50 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:20063) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVhLE-0001NF-DS for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 10:42:48 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7TEgk6T028720 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Aug 2015 14:42:47 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7TEgjc6017449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Aug 2015 14:42:46 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7TEgjm1026329; Sat, 29 Aug 2015 14:42:45 GMT MIME-Version: 1.0 Message-ID: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> Date: Sat, 29 Aug 2015 07:42:42 -0700 (PDT) From: Drew Adams To: Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <<9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <<7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <<83lhcv4wp4.fsf@gnu.org>> <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<87si73dsjt.fsf@mail.linkov.net>> <> <<83pp26373z.fsf@gnu.org>> In-Reply-To: <<83pp26373z.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -3.3 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (---) > > Please see the simple patch I sent, which I think takes care of this. >=20 > If we are going to extend highlighting beyond the displayed portion of > the buffer, then your proposed patch needs more work, IMO. AFAIU, > with your patch, setting lazy-highlight-max-at-a-time to, say, 2000, > will still limit the highlighting to the displayed portion, which > makes little sense to me, as the probability of finding more than 2000 > matches in a single window-full is practically zero, and so the user's > intent will not be honored (and the doc string will still be > misleading). Yes. As I said, more than once, the patch I submitted fixes the bug only "for a nil value". And I added: Feel free to adjust the fix. Or to extend it to also take a numeric value into account. But I will be happy if it is fixed at least for nil. My immediate need, for which there is an easy, quick fix, is to make the option work for nil. I certainly agree that it would be good to also make it work for large numeric values - which is why I invited such an additional fix. That will be useful. > Instead, I suggest to use a special non-nil value, e.g. zero or -1, to > indicate a limit to the current window's end, and treat any other > value literally, disregarding the window limits. (This will need to > be reflected in the documentation, of course.) That special value > should IMO be the default. Or maybe introduce a separate predicate > option for whether to limit to window start and end. That sounds OK to me. Except that you did not explicitly mention nil. Do you mean, by treat it literally, that it should behave for nil as it is advertised now: no limit at all? If so then I agree. IOW, I would like nil to behave as advertised: no limit. This is the use case that prompted me to file the bug and look for a solution. > Yes, this would be a backward-incompatible change, but I don't think > the difference will matter too much in most use cases, especially with > the default value of lazy-highlight-cleanup. Because this has never worked before for areas beyond the window, it does not really present backward compatibility problems. Unless you are considering someone who has set the value to 99999999 and continues to expect highlighting to be limited to the window. > Btw, another issue that arises in this regard is whether to highlight > beyond the screen only in the direction of the search (which AFAICS is > what your proposed patch does) or in both directions, especially when > the value of lazy-highlight-max-at-a-time is nil. Good point. My patch is not good enough here, though it is enough to temporarily switch directions (e.g., from C-s to C-r) to work around this incompleteness. That is the first (next) thing to do, I think: fix things completely for nil, so that it highlights all search hits (both directions). I will take another look when I get a chance, if no one beats me to it. That would also give users a real difference in behavior between a very large number and nil, which is good. There should be a way, which a very large number would provide, of getting a no-limit behavior for only the current search direction. (My patch currently does this (for nil), but that is not the behavior nil should provide, IMO.) I appreciate your interest in this and hope that we do get it fixed. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 29 17:19:50 2015 Received: (at 21092) by debbugs.gnu.org; 29 Aug 2015 21:19:50 +0000 Received: from localhost ([127.0.0.1]:42330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVnXS-00032A-HF for submit@debbugs.gnu.org; Sat, 29 Aug 2015 17:19:50 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:33645 helo=homiemail-a19.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVnXQ-000321-Fd for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 17:19:49 -0400 Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 9744D60408D; Sat, 29 Aug 2015 14:19:47 -0700 (PDT) Received: from localhost.linkov.net (m83-180-23-145.cust.tele2.ee [83.180.23.145]) (Authenticated sender: jurta@jurta.org) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 6E63A604089; Sat, 29 Aug 2015 14:19:46 -0700 (PDT) From: Juri Linkov To: Drew Adams Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <83lhcv4wp4.fsf@gnu.org>> <56e13714-27a7-47f9-93df-299b4a25457d@default>> <87si73dsjt.fsf@mail.linkov.net>> > <83pp26373z.fsf@gnu.org>> <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> Date: Sun, 30 Aug 2015 00:10:10 +0300 In-Reply-To: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> (Drew Adams's message of "Sat, 29 Aug 2015 07:42:42 -0700 (PDT)") Message-ID: <87oahpbxu1.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) > IOW, I would like nil to behave as advertised: no limit. This is the > use case that prompted me to file the bug and look for a solution. There is no bug. I have =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 s= et to nil in my .emacs for years, and it worked as intended to optimize the performance of the screen-limited lazy-highlighting. Please don't break this useful option. With your proposed changes Isearch will be horribly = slow to highlight all matches in a large buffer on every search state change. There is no need to highlight all matches in the buffer during Isearch. If you want a new feature, please create a new feature request with a subject like =E2=80=98Feature request: lazy-hi-lock on Isearch exi= t=E2=80=99 that will highlight all matches in the buffer after you exit Isearch. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 29 22:39:59 2015 Received: (at 21092) by debbugs.gnu.org; 30 Aug 2015 02:39:59 +0000 Received: from localhost ([127.0.0.1]:42388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVsXH-0001pS-EH for submit@debbugs.gnu.org; Sat, 29 Aug 2015 22:39:59 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:42651) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVsXF-0001pI-0s for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 22:39:58 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTV00M00J50X600@a-mtaout22.012.net.il> for 21092@debbugs.gnu.org; Sun, 30 Aug 2015 05:39:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTV00MW9JEJTV20@a-mtaout22.012.net.il>; Sun, 30 Aug 2015 05:39:55 +0300 (IDT) Date: Sun, 30 Aug 2015 05:40:01 +0300 From: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work In-reply-to: <87oahpbxu1.fsf@mail.linkov.net> X-012-Sender: halo1@inter.net.il To: Juri Linkov Message-id: <83r3ml1ou6.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21092 Cc: drew.adams@oracle.com, 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > From: Juri Linkov > Cc: Eli Zaretskii , 21092@debbugs.gnu.org > Date: Sun, 30 Aug 2015 00:10:10 +0300 > > > IOW, I would like nil to behave as advertised: no limit. This is the > > use case that prompted me to file the bug and look for a solution. > > There is no bug. I have ‘lazy-highlight-max-at-a-time’ set to nil > in my .emacs for years, and it worked as intended to optimize the > performance of the screen-limited lazy-highlighting. Please don't break > this useful option. With your proposed changes Isearch will be horribly slow > to highlight all matches in a large buffer on every search state change. > > There is no need to highlight all matches in the buffer during Isearch. What if someone wants to? > If you want a new feature, please create a new feature request > with a subject like ‘Feature request: lazy-hi-lock on Isearch exit’ > that will highlight all matches in the buffer after you exit Isearch. How about leaving the current meaning of nil as it is, i.e. limit the highlighting to the visible portion of the buffer, and introducing a special value like zero or -1 to mean highlight the whole buffer? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 01:39:23 2015 Received: (at 21092) by debbugs.gnu.org; 30 Aug 2015 05:39:24 +0000 Received: from localhost ([127.0.0.1]:42413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVvKt-0005wB-AZ for submit@debbugs.gnu.org; Sun, 30 Aug 2015 01:39:23 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:44247) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVvKq-0005w0-VA for 21092@debbugs.gnu.org; Sun, 30 Aug 2015 01:39:21 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7U5dIAh016646 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Aug 2015 05:39:19 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t7U5dIbg023127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Aug 2015 05:39:18 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7U5dIPP027331; Sun, 30 Aug 2015 05:39:18 GMT MIME-Version: 1.0 Message-ID: <937da1eb-4e72-410e-b024-907f9ad7d253@default> Date: Sat, 29 Aug 2015 22:39:15 -0700 (PDT) From: Drew Adams To: Eli Zaretskii , Juri Linkov Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> In-Reply-To: <83r3ml1ou6.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (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: -3.3 (---) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (---) > > > IOW, I would like nil to behave as advertised: no limit. This is the > > > use case that prompted me to file the bug and look for a solution. > > > > There is no bug. I have =E2=80=98lazy-highlight-max-at-a-time=E2=80=99= set to nil > > in my .emacs for years, and it worked as intended to optimize the > > performance of the screen-limited lazy-highlighting. Please don't brea= k > > this useful option. With your proposed changes Isearch will be horribl= y > > slow to highlight all matches in a large buffer on every search state > > change. > > > > There is no need to highlight all matches in the buffer during Isearch. >=20 > What if someone wants to? >=20 > > If you want a new feature, please create a new feature request > > with a subject like =E2=80=98Feature request: lazy-hi-lock on Isearch e= xit=E2=80=99 > > that will highlight all matches in the buffer after you exit Isearch. >=20 > How about leaving the current meaning of nil as it is, i.e. limit the > highlighting to the visible portion of the buffer, and introducing a > special value like zero or -1 to mean highlight the whole buffer? As I said earlier, I'm all for adding additional specific arguments for different behaviors - whatever is needed. But "the current meaning of nil", as it is documented, is not what the behavior is. I respect Juri's argument that the bug is quite old and that some people might be used to nil not doing what has been advertised for it and want it to continue doing what it has long been doing. That's a reasonable argument. Personally, I would prefer that nil be made to act as advertised, but it is OK with me if the decision is to keep the nil behavior as it is now, and so change its meaning from what is currently documented (IOW, change the doc and Customize UI so that they fit what nil currently does), as long as there is some (new) value for the option that does what the doc has been saying nil does: highlight all search hits - no limit on the highlighting. I don't care whether you call this a new feature or a bug fix. To me it is a bug fix, as indications are that the fixed behavior was the originally intended behavior. But who really knows? It doesn't matter to me what we call it. To me it is very useful to be able to have lazy highlighting highlight all search hits. To mention a use case, in case it makes any difference to you: I have code that lets you hit a key to search again (different search pattern) during the same or a subsequent Isearch invocation, and have this second search be limited _within_ the previous search hits. That is, the lazy-highlight zones from one search act as the search contexts (limits) for the next search. You can repeat this etc. This is a kind of progressive narrowing. And I have code that lets you search within defined areas (think of multiple regions), and there too you can hit a (different) key to refine the search. In this case, whole contexts that did not have a search hit from the first search are removed as candidates for the next search. IOW, the current search hits narrow the set of contexts for subsequent searching. This is another kind of progressive narrowing. In both cases, subsequent searches may well hit places that were offscreen during previous searches, because the addition of constraints (reduction of contexts) can reduce the matches. In this use case, it can be (and typically is) useful to lazy-highlight all search hits and (typically) to turn off `lazy-highlight-cleanup'. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 16:59:51 2015 Received: (at 21092) by debbugs.gnu.org; 30 Aug 2015 20:59:51 +0000 Received: from localhost ([127.0.0.1]:43132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9he-0006Fe-Eb for submit@debbugs.gnu.org; Sun, 30 Aug 2015 16:59:50 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:49620 helo=homiemail-a13.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZW9hc-0006FU-4j for 21092@debbugs.gnu.org; Sun, 30 Aug 2015 16:59:48 -0400 Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 0470A334072; Sun, 30 Aug 2015 13:59:47 -0700 (PDT) Received: from localhost.linkov.net (m91-131-183-248.cust.tele2.ee [91.131.183.248]) (Authenticated sender: jurta@jurta.org) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id C722A33406F; Sun, 30 Aug 2015 13:59:45 -0700 (PDT) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> Date: Sun, 30 Aug 2015 23:58:50 +0300 In-Reply-To: <83r3ml1ou6.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Aug 2015 05:40:01 +0300") Message-ID: <87h9ng4ho0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21092 Cc: drew.adams@oracle.com, 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) >> There is no need to highlight all matches in the buffer during Isearch. > > What if someone wants to? Why would someone want such a strange thing? Drew wanted to highlight all matches in the buffer only on quitting Isearch that is easily achievable with just (add-hook 'isearch-mode-end-hook (lambda () (highlight-regexp (regexp-quote isearch-string) 'lazy-highlight))) From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 30 18:39:55 2015 Received: (at 21092) by debbugs.gnu.org; 30 Aug 2015 22:39:56 +0000 Received: from localhost ([127.0.0.1]:43157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWBGV-0000cT-CL for submit@debbugs.gnu.org; Sun, 30 Aug 2015 18:39:55 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:45987) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWBGT-0000cL-7x for 21092@debbugs.gnu.org; Sun, 30 Aug 2015 18:39:54 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7UMdp9b004476 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Aug 2015 22:39:52 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7UMdpVi004628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Aug 2015 22:39:51 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7UMdnh1005000; Sun, 30 Aug 2015 22:39:50 GMT MIME-Version: 1.0 Message-ID: <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> Date: Sun, 30 Aug 2015 15:39:45 -0700 (PDT) From: Drew Adams To: Juri Linkov , Eli Zaretskii Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> In-Reply-To: <87h9ng4ho0.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21092 Cc: 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (--) > >> There is no need to highlight all matches in the buffer > >> during Isearch. > > > > What if someone wants to? >=20 > Why would someone want such a strange thing? I gave a pretty detailed explanation of a reasonable use case. > Drew wanted to highlight all matches in the buffer only > on quitting Isearch Not at all. The narrowing I mentioned can be done, as I said, during the same Isearch invocation. That is the more typical case, in fact. It is why I bind Isearch keys to the narrowing operations. Tt doesn't seem that you really want to know why anyone would want "such a strange thing". _You_ don't want it. That much seems clear. Sigh, another feature that will remain only for Isearch+, I guess. To me, this is not an additional feature. It is a bug fix. But I won't argue about it, and it's beside the point now. You clearly do not want this done. You have not wanted a boatload of features, whether it's searching within the active region (not needed, since a user can always narrow the buffer); search within text- or overlay-property zones; on-demand replacement of search hits during search;... NIH? Please at least fix the doc so that it matches what the code does, whether or not that matches what the original intention was. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 31 16:06:48 2015 Received: (at 21092) by debbugs.gnu.org; 31 Aug 2015 20:06:48 +0000 Received: from localhost ([127.0.0.1]:44059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWVLr-0004W7-S0 for submit@debbugs.gnu.org; Mon, 31 Aug 2015 16:06:48 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:54945 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWVLq-0004Vz-Fe for 21092@debbugs.gnu.org; Mon, 31 Aug 2015 16:06:47 -0400 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 264A631A078; Mon, 31 Aug 2015 13:06:43 -0700 (PDT) Received: from localhost.linkov.net (m212-53-118-114.cust.tele2.ee [212.53.118.114]) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPA id C265B31A070; Mon, 31 Aug 2015 13:06:41 -0700 (PDT) From: Juri Linkov To: Drew Adams Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> Date: Mon, 31 Aug 2015 23:01:34 +0300 In-Reply-To: <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> (Drew Adams's message of "Sun, 30 Aug 2015 15:39:45 -0700 (PDT)") Message-ID: <87y4grw7kx.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) > You clearly do not want this done. Not at all. I only disagree that it's a bug. =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 is just an optimization va= riable along with =E2=80=98lazy-highlight-initial-delay=E2=80=99, =E2=80=98lazy-= highlight-interval=E2=80=99 that users might want to tweak to improve performance where nil of =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 allows highlighting in one= loop that avoids delays on fast processors (it makes sense to change its default value to nil to match the modern hardware). A new feature to highlight the whole buffer would be useful as well to reduce flickering during Isearch. Currently when e.g. scrolling by one line lazy-highlight clears all matches on the screen, and re-highlights them with an additional line taken into account. That's because lazy-highlight is non-incremental. Highlighting the whole buffer could fix this visual effect. So unlike the current screen-limited lazy-highlighting that reacts to window-start/window-end changes, once whole-buffer lazy-highlighting finds all matches in the buffer it doesn't need to re-highlight them during Isearch navigation. A new option could be named e.g. (defcustom lazy-highlight-buffer nil) Again, its default value is depending on the average hardware. While I believe that highlighting all matches on the screen is suitable for most users, I'm not sure about highlighting all matches in a (possibly large) buffer in one loop. > You have not wanted a boatload of features, Yes, I resist a bloatload of features, but I'm happy with adding features that solve a complex usability problem in a simple way. > whether it's searching within the active region (not needed, > since a user can always narrow the buffer); Because it's more useful to extend the bounds of the active region using Isearch. > search within text- or overlay-property zones; There is an unfinished feature request bug#15245. > on-demand replacement of search hits during search Can you find a bug# for this? > Please at least fix the doc so that it matches what the > code does, whether or not that matches what the original > intention was. Then the docstring could point to the new option =E2=80=98lazy-highlight-= buffer=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 31 17:35:38 2015 Received: (at 21092) by debbugs.gnu.org; 31 Aug 2015 21:35:38 +0000 Received: from localhost ([127.0.0.1]:44175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWWjq-0008R0-3n for submit@debbugs.gnu.org; Mon, 31 Aug 2015 17:35:38 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:43762) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWWjm-0008Qp-A6 for 21092@debbugs.gnu.org; Mon, 31 Aug 2015 17:35:35 -0400 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7VLZWMs005982 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Aug 2015 21:35:33 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7VLZW5J028679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 21:35:32 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t7VLZW5h011455; Mon, 31 Aug 2015 21:35:32 GMT MIME-Version: 1.0 Message-ID: <719ef340-0997-40fe-b1d8-c20c2a69155e@default> Date: Mon, 31 Aug 2015 14:35:31 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> In-Reply-To: <87y4grw7kx.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0022.oracle.com [156.151.31.74] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (--) > > You clearly do not want this done. >=20 > Not at all. I only disagree that it's a bug. Good to hear. But it sure didn't sound like it: J >>> There is no need to highlight all matches in the buffer J >>> during Isearch. E >> What if someone wants to? J > Why would someone want such a strange thing? Anyway, I'm glad you agree now that such a strange thing can be useful. > =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 is just an optimization va= riable > along with =E2=80=98lazy-highlight-initial-delay=E2=80=99, =E2=80=98lazy-= highlight-interval=E2=80=99 > that users might want to tweak to improve performance where nil of > =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 allows highlighting in one= loop > that avoids delays on fast processors (it makes sense to change > its default value to nil to match the modern hardware). >=20 > A new feature to highlight the whole buffer would be useful as well > to reduce flickering during Isearch. Currently when e.g. scrolling > by one line lazy-highlight clears all matches on the screen, and > re-highlights them with an additional line taken into account. > That's because lazy-highlight is non-incremental. Whole buffer OR rest-of-buffer forward or backward. Au choix. Both behaviors are useful. > Highlighting the whole buffer could fix this visual effect. > So unlike the current screen-limited lazy-highlighting that reacts > to window-start/window-end changes, once whole-buffer lazy-highlighting > finds all matches in the buffer it doesn't need to re-highlight them > during Isearch navigation. >=20 > A new option could be named e.g. (defcustom lazy-highlight-buffer nil) > Again, its default value is depending on the average hardware. > While I believe that highlighting all matches on the screen > is suitable for most users, I'm not sure about highlighting > all matches in a (possibly large) buffer in one loop. It's not clear how you see the two options interacting (or not). If you are telling Isearch to highlight all matches and you are also telling it to highlight at most 10, for example. And what about the current nil value of `lazy-highlight-max-at-a-time', which also says (currently) that it means highlight "all"? Not clear why you want a separate option for this. It cannot be used in combination with `lazy-highlight-max-at-a-time', can it? If the behaviors are mutually exclusive, then why not just add another value or two for `lazy-highlight-max-at-a-time'? A second question concerns how to control whether this acts only in the current search direction or in both directions. In the patch I sent, a user gets all matches in the search direction. If s?he wants all matches in both directions it is enough to briefly hit the other direction key (e.g. hit `C-r' if searching forward). The use I make of the all-matches behavior will be togglable,=20 and I will want to control what the behaviors toggled are. For exmaple, I might want a toggle between max=3D10 and whole-buffer. Or between whole-buffer and remainder-of-buffer (in search direction). > > whether it's searching within the active region (not needed, > > since a user can always narrow the buffer); > > Because it's more useful to extend the bounds of the active > region using Isearch. Dunno what that means. Please elaborate. And please say why you think it is always more useful than limiting search to the region. Whatever you mean by it, why should it be a question only of design-time either-or? In Isearch+, limitation of search to the active region is optional, and you can change the behavior anytime on the fly (toggle `C-x n'). (Deactivation of the active region is also optional.) > > search within text- or overlay-property zones; >=20 > There is an unfinished feature request bug#15245. On-demand replacement of search hits is available in Isearch+. At the time I replied in that bug thread, I guess I had not yet added this feature. It seems I added it a month after I posted there. Anyway, that too is available. AFAIK, with Isearch+ you can do all that is requested in the bug. And as you say in the bug thread, you can also limit `query-replace' to such text zones using `isearch-filter-predicate'. > > on-demand replacement of search hits during search >=20 > Can you find a bug# for this? It's not a bug, AFAIK. It's an Isearch+ feature. http://www.emacswiki.org/emacs/IsearchPlus#isearchp-replace-on-demand You can perform an arbitrary action on the current search hit, on demand. By default, the action is replacement. > > Please at least fix the doc so that it matches what the > > code does, whether or not that matches what the original > > intention was. >=20 > Then the docstring could point to the new option > =E2=80=98lazy-highlight-buffer=E2=80=99. See above. I'm all for adding the ability to highlight beyond the current window, and I am glad to hear you are also for it. But it's unclear why a separate option should be used, instead of additional option values for `lazy-highlight-max-at-a-time'. And it's unclear how a user can get up-to-the-buffer/region-limit behavior in one direction only. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 18:58:56 2015 Received: (at 21092) by debbugs.gnu.org; 1 Sep 2015 22:58:56 +0000 Received: from localhost ([127.0.0.1]:45475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWuW0-0001Ry-3f for submit@debbugs.gnu.org; Tue, 01 Sep 2015 18:58:56 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:57223 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWuVw-0001Rj-UU for 21092@debbugs.gnu.org; Tue, 01 Sep 2015 18:58:54 -0400 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D415E45808A; Tue, 1 Sep 2015 15:58:51 -0700 (PDT) Received: from localhost.linkov.net (m212-53-118-114.cust.tele2.ee [212.53.118.114]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id B5B5D458088; Tue, 1 Sep 2015 15:58:50 -0700 (PDT) From: Juri Linkov To: Drew Adams Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> <719ef340-0997-40fe-b1d8-c20c2a69155e@default> Date: Wed, 02 Sep 2015 01:55:03 +0300 In-Reply-To: <719ef340-0997-40fe-b1d8-c20c2a69155e@default> (Drew Adams's message of "Mon, 31 Aug 2015 14:35:31 -0700 (PDT)") Message-ID: <87mvx5oim0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) >> > You clearly do not want this done. >> >> Not at all. I only disagree that it's a bug. > > Good to hear. But it sure didn't sound like it: > > J >>> There is no need to highlight all matches in the buffer > J >>> during Isearch. > E >> What if someone wants to? > J > Why would someone want such a strange thing? > > Anyway, I'm glad you agree now that such a strange thing can be useful. I tried to find a useful application for this feature, and finally found. > Whole buffer OR rest-of-buffer forward or backward. Au choix. > Both behaviors are useful. Since you can scroll up or down, highlighting the whole buffer is unavoid= able. > Not clear why you want a separate option for this. It cannot be > used in combination with `lazy-highlight-max-at-a-time', can it? Of course, it is useful in combination with =E2=80=98lazy-highlight-max-a= t-a-time=E2=80=99 that can define the incrementality (how many steps to do) regardless whether highlighting the whole buffer or only matches on the screen. > A second question concerns how to control whether this acts > only in the current search direction or in both directions. We can highlight only in the search direction because regexp search might match different results depending on direction. So you need to switch directions with =E2=80=98C-r=E2=80=99 to re-highlig= ht the buffer. > For exmaple, I might want a toggle between max=3D10 and > whole-buffer. This will be possible with two separate variables: the existing =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 to toggle between max=3D10 and max=3Dnil and the new =E2=80=98lazy-highlight-buffer=E2=80=99 to toggle between whole-buffer and screen-only implemented by this small patch: diff --git a/lisp/isearch.el b/lisp/isearch.el index 8d4bf24..a53b314 100644 --- a/lisp/isearch.el +++ b/lisp/isearch.el @@ -332,6 +332,13 @@ (defcustom lazy-highlight-max-at-a-time 20 (integer :tag "Some")) :group 'lazy-highlight) =20 +(defcustom lazy-highlight-buffer nil + "Highlight the whole buffer (for `lazy-highlight'). +A value of nil means highlight all matches on the screen. +A value of t means highlight all matches in the whole buffer." + :type 'boolean + :group 'lazy-highlight) + (defface lazy-highlight '((((class color) (min-colors 88) (background light)) (:background "paleturquoise")) @@ -3029,10 +3040,12 @@ (defun isearch-lazy-highlight-new-loop (&optional= beg end) isearch-lax-whitespace)) (not (eq isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace)) - (not (=3D (window-start) - isearch-lazy-highlight-window-start)) - (not (=3D (window-end) ; Window may have been split/j= oined. - isearch-lazy-highlight-window-end)) + (if lazy-highlight-buffer nil + (not (=3D (window-start) + isearch-lazy-highlight-window-start))) + (if lazy-highlight-buffer nil + (not (=3D (window-end) ; Window may have been split/j= oined. + isearch-lazy-highlight-window-end))) (not (eq isearch-forward isearch-lazy-highlight-forward)) ;; In case we are recovering from an error. @@ -3092,13 +3105,13 @@ (defun isearch-lazy-highlight-search () (+ isearch-lazy-highlight-start ;; Extend bound to match whole string at point (1- (length isearch-lazy-highlight-last-string))) - (window-end))) + (if lazy-highlight-buffer (point-max) (window-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-start)))))) + (if lazy-highlight-buffer (point-min) (window-start))))))) ;; Use a loop like in `isearch-search'. (while retry (setq success (isearch-search-string @@ -3142,12 +3155,12 @@ (defun isearch-lazy-highlight-update () (if isearch-lazy-highlight-forward (if (=3D mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-start - (window-end))) + (if lazy-highlight-buffer (point-max) (window-end)))) (setq found nil) (forward-char 1)) (if (=3D mb (if isearch-lazy-highlight-wrapped isearch-lazy-highlight-end - (window-start))) + (if lazy-highlight-buffer (point-min) (window-start)))) (setq found nil) (forward-char -1))) =20 @@ -3174,12 +3187,12 @@ (defun isearch-lazy-highlight-update () (setq isearch-lazy-highlight-wrapped t) (if isearch-lazy-highlight-forward (progn - (setq isearch-lazy-highlight-end (window-start)) + (setq isearch-lazy-highlight-end (if lazy-highlight-buffer (point= -min) (window-start))) (goto-char (max (or isearch-lazy-highlight-start-limit (point-min= )) - (window-start)))) - (setq isearch-lazy-highlight-start (window-end)) + (if lazy-highlight-buffer (point-min) (window-start))))) + (setq isearch-lazy-highlight-start (if lazy-highlight-buffer (point-m= ax) (window-end))) (goto-char (min (or isearch-lazy-highlight-end-limit (point-max)) - (window-end)))))))) + (if lazy-highlight-buffer (point-max) (window-end))))))))) (unless nomore (setq isearch-lazy-highlight-timer (run-at-time lazy-highlight-interval nil From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 01 20:07:16 2015 Received: (at 21092) by debbugs.gnu.org; 2 Sep 2015 00:07:16 +0000 Received: from localhost ([127.0.0.1]:45487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWva7-0002yB-P4 for submit@debbugs.gnu.org; Tue, 01 Sep 2015 20:07:16 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:37486) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWva6-0002y4-5Q for 21092@debbugs.gnu.org; Tue, 01 Sep 2015 20:07:14 -0400 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 t8207CEM011830 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2015 00:07:13 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8207C4R007301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Sep 2015 00:07:12 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8207CF8031861; Wed, 2 Sep 2015 00:07:12 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 1 Sep 2015 17:07:11 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> <719ef340-0997-40fe-b1d8-c20c2a69155e@default> <87mvx5oim0.fsf@mail.linkov.net> In-Reply-To: <87mvx5oim0.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (--) > I tried to find a useful application for this feature, and finally found. Great. What's the application? > > Whole buffer OR rest-of-buffer forward or backward. Au choix. > > Both behaviors are useful. >=20 > Since you can scroll up or down, highlighting the whole buffer is > unavoidable. I don't understand. Can you elaborate a bit? With the patch I sent it seemed to be avoided. When searching forward, the only matches before point that got highlighted were those in the window. IIUC, this is not important to me, but I would like to understand. > > Not clear why you want a separate option for this. It cannot be > > used in combination with `lazy-highlight-max-at-a-time', can it? >=20 > Of course, it is useful in combination with =E2=80=98lazy-highlight-max-a= t-a-time=E2=80=99 > that can define the incrementality (how many steps to do) regardless > whether highlighting the whole buffer or only matches on the screen. I see now that I misunderstood what was meant by "at a time" in "max-at-a-time". I was thinking that it referred to all of the highlighting for a given input (e.g. after an input change). Instead, it refers to one invocation of `isearch-lazy-highlight-update', whose loop runs only `lazy-highlight-max-at-a-time' iterations. And `*-update' can get reinvoked by the timer to complete the highlighting for the input. > > A second question concerns how to control whether this acts > > only in the current search direction or in both directions. >=20 > We can highlight only in the search direction because regexp > search might match different results depending on direction. > So you need to switch directions with =E2=80=98C-r=E2=80=99 to re-highlig= ht > the buffer. You just said that "highlighting the whole buffer is unavoidable", so I am a bit confused. Now you seem to be saying that we can highlight only in one direction at a time. Maybe you could elaborate a bit here? > > For exmaple, I might want a toggle between max=3D10 and > > whole-buffer. >=20 > This will be possible with two separate variables: > the existing =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 > to toggle between max=3D10 and max=3Dnil > and the new =E2=80=98lazy-highlight-buffer=E2=80=99 > to toggle between whole-buffer and screen-only > implemented by this small patch: I misunderstood max-at-a-time. So maybe the doc for it needs clarifying wrt what is meant by at a time etc. The doc and defcustom need fixing anyway, for the confusion over the meaning of "all matches" etc., discussed previously. Anyway, your patch looks good. It is essentially the same as mine, but using `lazy-highlight-buffer' instead of a nil value of `lazy-highlight-max-at-a-time'. I understand now that they have different purposes. The difference is that I did not change the occurrences of `window-(start|end)' in `isearch-lazy-highlight-new-loop'. I wasn't sure it was needed (not fully understanding it), and I didn't notice a problem without it. But I'm glad that you, knowing more, made the same change there as well. Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 02 18:58:45 2015 Received: (at 21092) by debbugs.gnu.org; 2 Sep 2015 22:58:45 +0000 Received: from localhost ([127.0.0.1]:47038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGzN-0001gN-8y for submit@debbugs.gnu.org; Wed, 02 Sep 2015 18:58:45 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45401 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXGzL-0001gF-7z for 21092@debbugs.gnu.org; Wed, 02 Sep 2015 18:58:44 -0400 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 1A87E458087; Wed, 2 Sep 2015 15:58:42 -0700 (PDT) Received: from localhost.linkov.net (m212-53-123-180.cust.tele2.ee [212.53.123.180]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id E5FEC458083; Wed, 2 Sep 2015 15:58:40 -0700 (PDT) From: Juri Linkov To: Drew Adams Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> <719ef340-0997-40fe-b1d8-c20c2a69155e@default> <87mvx5oim0.fsf@mail.linkov.net> Date: Thu, 03 Sep 2015 01:40:10 +0300 In-Reply-To: (Drew Adams's message of "Tue, 1 Sep 2015 17:07:11 -0700 (PDT)") Message-ID: <87bndka1it.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 Cc: Eli Zaretskii , 21092@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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.7 (/) >> I tried to find a useful application for this feature, and finally fou= nd. > > Great. What's the application? Reducing flicker. >> > Whole buffer OR rest-of-buffer forward or backward. Au choix. >> > Both behaviors are useful. >> >> Since you can scroll up or down, highlighting the whole buffer is >> unavoidable. > > I don't understand. Can you elaborate a bit? With =E2=80=98isearch-allow-scroll=E2=80=99 you can scroll backwards to p= revious parts of the buffer that need to display highlighted matches too. >> > A second question concerns how to control whether this acts >> > only in the current search direction or in both directions. >> >> We can highlight only in the search direction because regexp >> search might match different results depending on direction. >> So you need to switch directions with =E2=80=98C-r=E2=80=99 to re-high= light >> the buffer. > > You just said that "highlighting the whole buffer is unavoidable", > so I am a bit confused. Now you seem to be saying that we can > highlight only in one direction at a time. Maybe you could > elaborate a bit here? Highlighting the whole buffer needs to be in the same direction as the current search direction. But =E2=80=98isearch-lazy-highlight-upd= ate=E2=80=99 already takes care about this. > The difference is that I did not change the occurrences of > `window-(start|end)' in `isearch-lazy-highlight-new-loop'. > I wasn't sure it was needed (not fully understanding it), > and I didn't notice a problem without it. You can see the difference when scrolling by one line with e.g. =E2=80=98scroll-down-line=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 23 20:02:05 2015 Received: (at 21092) by debbugs.gnu.org; 24 Dec 2015 01:02:05 +0000 Received: from localhost ([127.0.0.1]:33105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aBuI9-0001uG-LT for submit@debbugs.gnu.org; Wed, 23 Dec 2015 20:02:05 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:43807 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aBuI8-0001u1-AX for 21092@debbugs.gnu.org; Wed, 23 Dec 2015 20:02:04 -0500 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id CE2D945807B for <21092@debbugs.gnu.org>; Wed, 23 Dec 2015 17:02:03 -0800 (PST) Received: from localhost.linkov.net (m83-191-222-227.cust.tele2.ee [83.191.222.227]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 2611C458079 for <21092@debbugs.gnu.org>; Wed, 23 Dec 2015 17:02:02 -0800 (PST) From: Juri Linkov To: 21092@debbugs.gnu.org Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> <719ef340-0997-40fe-b1d8-c20c2a69155e@default> <87mvx5oim0.fsf@mail.linkov.net> Date: Thu, 24 Dec 2015 02:47:15 +0200 In-Reply-To: <87mvx5oim0.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 02 Sep 2015 01:55:03 +0300") Message-ID: <8737usbr4k.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.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.7 (/) X-Debbugs-Envelope-To: 21092 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.7 (/) > the new =E2=80=98lazy-highlight-buffer=E2=80=99 to toggle between whole= -buffer and > screen-only implemented by this small patch: Commenting out window-local lazy-highlighting overlay in bug#17453 ;; 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-face) - (overlay-put ov 'window (selected-window)))) + (overlay-put ov 'face lazy-highlight-face))) + ;(overlay-put ov 'window (selected-window)))) produces such deficiency that when two windows are displaying different p= arts of the same buffer (without using follow-mode), sometimes lazy-highlighte= d matches are partially (i.e. not all matches) displayed in non-current window when lazy-highlighting boundary of the selected window is in the middle of other window. This causes false impression that other window i= s responsible to highlight all visible matches but fails to do so. A solution is to install the 3rd patch posted by Artur in http://debbugs.gnu.org/17453#89 that adds a new option =E2=80=98all-windo= ws=E2=80=99 to =E2=80=98isearch-lazy-highlight=E2=80=99. Then we could setq-local it to= =E2=80=98all-windows=E2=80=99 in =E2=80=98follow-mode=E2=80=99, and don't highlight matches in other wi= ndows by default (keeping its old behavior). The same solution could be applied to bug#21092, to add a new option =E2=80=98buffer=E2=80=99 to =E2=80=98isearch-lazy-highlight=E2=80=99 to l= azy-highlight the whole buffer. Then =E2=80=98follow-mode=E2=80=99 should check it, and override it with = buffer-local =E2=80=98all-windows=E2=80=99 only when it was =E2=80=98t=E2=80=99 initia= lly. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 19:19:57 2017 Received: (at 21092-done) by debbugs.gnu.org; 22 Feb 2017 00:19:57 +0000 Received: from localhost ([127.0.0.1]:49416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgKez-0004IY-4l for submit@debbugs.gnu.org; Tue, 21 Feb 2017 19:19:57 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:35132 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cgKex-0004IQ-Nd for 21092-done@debbugs.gnu.org; Tue, 21 Feb 2017 19:19:56 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id B5B192B206D; Tue, 21 Feb 2017 16:19:52 -0800 (PST) Received: from localhost.linkov.net (m212-107-59-228.cust.tele2.ee [212.107.59.228]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id DAA9A2B206A; Tue, 21 Feb 2017 16:19:51 -0800 (PST) From: Juri Linkov To: 21092-done@debbugs.gnu.org Subject: Re: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Organization: LINKOV.NET References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> <87h9ng4ho0.fsf@mail.linkov.net> <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> <87y4grw7kx.fsf@mail.linkov.net> <719ef340-0997-40fe-b1d8-c20c2a69155e@default> <87mvx5oim0.fsf@mail.linkov.net> <8737usbr4k.fsf@mail.linkov.net> Date: Wed, 22 Feb 2017 02:16:35 +0200 In-Reply-To: <8737usbr4k.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 24 Dec 2015 02:47:15 +0200") Message-ID: <874lzn13mk.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.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.1 (/) X-Debbugs-Envelope-To: 21092-done Cc: Drew Adams 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.1 (/) > The same solution could be applied to bug#21092, to add a new option > =E2=80=98buffer=E2=80=99 to =E2=80=98isearch-lazy-highlight=E2=80=99 to= lazy-highlight the whole buffer. > Then =E2=80=98follow-mode=E2=80=99 should check it, and override it wit= h buffer-local > =E2=80=98all-windows=E2=80=99 only when it was =E2=80=98t=E2=80=99 init= ially. I fixed the docstring of =E2=80=98lazy-highlight-max-at-a-time=E2=80=99 mentioned in the subject line, and closing this bug. Drew, if you think we need to add a new option =E2=80=98buffer=E2=80=99 t= o =E2=80=98isearch-lazy-highlight=E2=80=99, then please create a separate f= eature request. From unknown Sun Jun 15 01:09:05 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 22 Mar 2017 11: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