From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Date: Sat, 29 Aug 2015 22:39:15 -0700 (PDT) Message-ID: <937da1eb-4e72-410e-b024-907f9ad7d253@default> References: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> <87oahpbxu1.fsf@mail.linkov.net> <83r3ml1ou6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440913228 25657 80.91.229.3 (30 Aug 2015 05:40:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 05:40:28 +0000 (UTC) Cc: 21092@debbugs.gnu.org To: Eli Zaretskii , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 30 07:40:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVvLg-0003Sq-20 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 07:40:12 +0200 Original-Received: from localhost ([::1]:56813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVvLf-00073N-Q8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Aug 2015 01:40:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVvLb-00070T-O4 for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 01:40:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVvLW-0006N4-Ni for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 01:40:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVvLW-0006Mr-L5 for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 01:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVvLV-0005x5-Vt for bug-gnu-emacs@gnu.org; Sun, 30 Aug 2015 01:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Aug 2015 05:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21092 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21092-submit@debbugs.gnu.org id=B21092.144091316422832 (code B ref 21092); Sun, 30 Aug 2015 05:40:01 +0000 Original-Received: (at 21092) by debbugs.gnu.org; 30 Aug 2015 05:39:24 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 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)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105972 Archived-At: > > > 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'.