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: Thu, 23 Nov 2017 15:53:25 -0800 (PST) Message-ID: <314f93aa-a8b9-422b-af24-6755f0015b77@default> References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <87efoomzr9.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511481254 7165 195.159.176.226 (23 Nov 2017 23:54:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Nov 2017 23:54: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 Fri Nov 24 00:54:10 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 1eI1Jp-0001Nt-MJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 Nov 2017 00:54:09 +0100 Original-Received: from localhost ([::1]:46661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI1Jv-0001od-IR for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Nov 2017 18:54:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eI1Jl-0001ng-Uk for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2017 18:54:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eI1Jj-0004Kq-BM for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2017 18:54:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45704) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eI1Jj-0004KP-5S for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2017 18:54:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eI1Ji-0008VY-SJ for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2017 18:54: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: Thu, 23 Nov 2017 23:54: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.151148121632658 (code B ref 29360); Thu, 23 Nov 2017 23:54:02 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 23 Nov 2017 23:53:36 +0000 Original-Received: from localhost ([127.0.0.1]:54383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eI1JH-0008Uf-N7 for submit@debbugs.gnu.org; Thu, 23 Nov 2017 18:53:35 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:24235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eI1JF-0008US-PS for 29360@debbugs.gnu.org; Thu, 23 Nov 2017 18:53:34 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vANNrRkN004179 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Nov 2017 23:53:27 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vANNrRah004078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 Nov 2017 23:53:27 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vANNrQkh023100; Thu, 23 Nov 2017 23:53:26 GMT In-Reply-To: <87efoomzr9.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] 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:140283 Archived-At: > >> Are you sure this should be part of isearch, not hi-lock? Yes, as I said. And I gave several reasons. > hi-lock is not about font-lock highlighting too > when font-lock is not active. See the variable > =E2=80=98hi-lock-highlight-range=E2=80=99 with its default limit of 20000= 0. >=20 > I'm thinking about using lazy-highlight in hi-lock > to overcome this limitation after adding support > for full-buffer to lazy-highlight. Maybe better > to generalize the current implementation of > isearch-lazy-highlight-update to apply a function > given as an argument to perform different actions > on the found matches (by default, adding the lazy-highlight > overlay, and for hi-lock adding the hi-lock-overlay). A hi-lock feature doesn't correspond at all to what I requested for this enhancement. I specifically want this as a feature of Isearch, for the reasons I gave. I guess I'll need to do this for only my own code. It's easy enough to do. I was hoping not to have to maintain yet another difference from vanilla Isearch, and to give vanilla Isearch the same potential benefits. Sorry I mentioned it now. After you do what you will do it will increase my maintenance burden rather than lessening it, and it won't move vanilla Emacs in the same direction. I already provide users a way to act on the current search hit in arbitrary ways. The default action is replacement - the default replacement is "" (delete). Your way of providing something similar will no doubt not offer exactly the same thing, and will anyway not use the same approach of implementation. No good deed goes unpunished, I guess. I suppose I should be happy to have inspired an improvement in Emacs, even if it's not the improvement I requested.