From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Date: Mon, 20 Nov 2017 14:40:52 -0800 (PST) Message-ID: <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511217734 30686 195.159.176.226 (20 Nov 2017 22:42:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 22:42:14 +0000 (UTC) Cc: 29360@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 20 23:42:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGulT-0007Rd-Fa for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Nov 2017 23:42:07 +0100 Original-Received: from localhost ([::1]:60083 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGulZ-0004jG-1j for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Nov 2017 17:42:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGulS-0004i0-06 for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 17:42:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGulO-0006JQ-Qo for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 17:42:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40942) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eGulO-0006JI-MH for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 17:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eGulO-0002ua-FV for bug-gnu-emacs@gnu.org; Mon, 20 Nov 2017 17:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2017 22:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29360 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29360-submit@debbugs.gnu.org id=B29360.151121766411106 (code B ref 29360); Mon, 20 Nov 2017 22:42:02 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 20 Nov 2017 22:41:04 +0000 Original-Received: from localhost ([127.0.0.1]:49620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGukS-0002t4-J2 for submit@debbugs.gnu.org; Mon, 20 Nov 2017 17:41:04 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGukQ-0002sD-T4 for 29360@debbugs.gnu.org; Mon, 20 Nov 2017 17:41:03 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAKMet4i018467 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 22:40:55 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAKMesaQ015565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 22:40:54 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vAKMeraQ001418; Mon, 20 Nov 2017 22:40:54 GMT In-Reply-To: <87shd8lli4.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:140181 Archived-At: > > See bug #21092 for the motivation and reasons behind this bug report. > > The aim of that bug report was never taken care of, which was to let > > you force lazy-highlight highlighting on the full visible portion of > > the buffer (where that refers to the full buffer or the current > > buffer restriction). IOW, optionally do not restrict highlighting > > to what is currently on screen, as is done now. > > > > The #21092 bug report mistakenly took a `nil' value of > > `lazy-highlight-max-at-a-time' as meaning just that - just what the doc > > said: act on the full buffer, not just on the text that is currently in > > the window. The true meaning of nil for that variable is just to > > highlight all of the search hits visible in the window. > > > > This new bug aims to finally get what was really being requested in > > #21092: the ability to cause lazy highlight to act on the full buffer, > > not just the text currently visible in the window. > > > > The outcome of #21092 and other bugs led to the creation of variable > > `isearch-lazy-highlight'. At the end of #21092, realizing that closing > > #21092 did not, in fact, respond to the aim of #21092, Juri suggested > > that a separate report be filed, to request a new possible value for > > `isearch-lazy-highlight' which will cause the full buffer to get the > > lazy-highlight highlighting. That is the purpose of this bug report: > > please add such a `buffer' or `full-buffer' value. >=20 > Are you sure this should be part of isearch, not hi-lock? Yes. > Isearch used to highlight only the visible part of the buffer Isearch also used to highlight only the current search hit - no lazy-highlighting at all. So what? Did someone back then argue that we shouldn't add lazy highlighting because Isearch is only about finding the next search hit? No. Highlighting all visible hits is an improvement over the pre-Emacs 22 behavior. Being able to optionally highlight all hits (visible in the window or not) adds other advantages. > because it is modal and doesn't allow the user to scroll the > current search match out of view. Whereas hi-lock is intended > to highlight all matches in the whole buffer. Just because Isearch has not previously had an option to highlight all matches is not a reason it should not offer such an option. This is only about _optional_ behavior; it proposes no change to the default lazy-highlighting behavior. No relation to hi-lock. This is not about font-lock highlighting. It is about the "lazy-highlighting"=20 of Isearch, during Isearch, for Isearch, being extended to cover the whole buffer. It is about incremental search: being able to change the set of matches incrementally. You can (now) set `lazy-highlight-cleanup' to nil (you can even toggle it during Isearch) to keep the lazy-highlighting when search is done. That can be very useful. And doing likewise without needing to totally exit Isearch can also be useful, e.g., to search only _within_ the lazy highlights - i.e., progressing search narrowing. E.g, combine multiple simple regexps (ANDing them) vs trying to come up with a single, complex regexp to do the same thing. Or being able to flip to searching the complement of the lazy highlights. Any such features expect, to be really useful, that the lazy-highlighted zones include all of the search hits, over the entire search space. They are about a new search that is related to the previous search. They should not be limited to whatever hits were visible in the current window for the previous search. Just because this is not the classic Isearch use case is not a reason it isn't usefully added to Isearch. It is only about isearching - isearching zones that have been found by isearching. It's about isearching isearches... Any argument about not being able to see highlighting past the window is irrelevant - this is not about scrolling. The motivation was already discussed in bug #21092. That bug should have taken care of this, but I expressed the need in terms of `lazy-highlight-max-at-a-time', having misunderstood that variable's purpose because its doc string described, for a nil value, just what this bug (#29360) asks for.