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, 18 Oct 2018 16:25:03 -0700 (PDT) Message-ID: References: <7ec3c778-ee77-48c9-ba10-f21202cac955@default> <87shd8lli4.fsf@mail.linkov.net> <36f5e57c-2eb3-45eb-ae43-3f8fdf7586dd@default> <60f1b355-7455-4bb9-ae3d-294e1494a9d9@default> <87va5yhpaq.fsf@mail.linkov.net> 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 1539905055 30396 195.159.176.226 (18 Oct 2018 23:24:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Oct 2018 23:24:15 +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 Oct 19 01:24:10 2018 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 1gDHeE-0007oK-C2 for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2018 01:24:10 +0200 Original-Received: from localhost ([::1]:45185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDHgK-0003dx-HP for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Oct 2018 19:26:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDHg7-0003dg-Qs for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 19:26:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDHg2-0002T5-Nz for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 19:26:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53314) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDHg2-0002Sh-Gs for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 19:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gDHg1-0006Rb-Vz for bug-gnu-emacs@gnu.org; Thu, 18 Oct 2018 19:26: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: Thu, 18 Oct 2018 23:26:01 +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.153990511424702 (code B ref 29360); Thu, 18 Oct 2018 23:26:01 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 18 Oct 2018 23:25:14 +0000 Original-Received: from localhost ([127.0.0.1]:57569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDHfG-0006QM-0D for submit@debbugs.gnu.org; Thu, 18 Oct 2018 19:25:14 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:54880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDHfE-0006Q7-90 for 29360@debbugs.gnu.org; Thu, 18 Oct 2018 19:25:12 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9INOUYP162713; Thu, 18 Oct 2018 23:25:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=SIUut8roxXVY49GmPXNkf9evzpox68O1U8rGlYvnhaM=; b=XnbQyqYNu0Kcg1u3AdIDXBm+aonxEgi8oOc/s6r7bN5r3/C7WEyeui7Aa2b0zVYPbwks slIiEMfCSrFzVX0EJQluw+ce40uHYynzq2V4a3zJ2j/HnbPazPIQD3gqcjoR+uNiEkUU iRyclOL5VOevGuhSN9VZucd1bbUbk8ouS99kJ+huLTH7oTvQ1sYBAmtMQFN/sTq+u86v sJE1mvQNELn/c+musZQMliu9xRY0MUd041VlxQL2nGtYPzkfLtSZ96dnQcHLVZYGoJs/ 2mRXDYLtf+pw45UIUJniG02q3TkG4nwH1afx/rmlkJ34GBjM3mCGz76HpcqfUUQKvEqc wA== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2n38nqhasv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:25:05 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9INP4dq031912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:25:05 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9INP4tO004667; Thu, 18 Oct 2018 23:25:04 GMT In-Reply-To: <87va5yhpaq.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9050 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180197 X-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:151410 Archived-At: > > It would really be good if this enhancement were made - for the > > reasons I gave in bug #21092, and for other reasons. You asked me > > (in bug #21092) to file this bug if I thought we needed such a > > full-buffer possibility. This enhancement request was the result. >=20 > Actually, a full-buffer lazy-highlighting possibility already exists: >=20 > (setq lazy-highlight-cleanup nil) > (add-hook 'isearch-mode-end-hook > (lambda () > (setq window-group-start-function (lambda (_w) (point-min))= ) > (setq window-group-end-function (lambda (_w _u) (point-max)= )))) Thanks for this info. I don't really understand it, though. `C-h v window-g= roup-start-function' tells me nothing, for instance - no doc, apparently. (FWIW, I already use `isearch-mode-end-hook' quite a bit. Not that another addition would necessarily break the bank. ;-)) > But I agree that more straightforward customization would be better > with a clear value of the customizable variable. Thank you. Will you please implement that when you get a chance? > > Did you not have a patch that took care of this? IIRC you then found > > a problem with it wrt `follow-mode', but I thought you had a solution > > for that too. (I thought the latter solution was provided by Artur's > > `all-windows' value for `isearch-lazy-highlight' etc., which was added.= ) >=20 > That patch was installed more than a year ago. What is that patch? Is this about `window-group-start|end-function' or is there some other way to force lazy highlighting to be done throughout the buffer? If this is patch is now reflected in isearch.el, where would I see it there? > > What's the status of this feature? Can we add it to Emacs now? > > I hope so. >=20 > The reason why it's not yet finished is because it was unclear how to > integrate it with another similar feature of matches-counting (that count= s > the number of matches in the full buffer). The reasoning is the followin= g: > both features require using the same loop in isearch-lazy-highlight > extending it to operate on the full buffer. I know you will argue that > these are unrelated features and should be treated separately. I won't argue any such thing, as I know nothing about this stuff. ;-) > But implementation-wise they have only one difference: >=20 > 1. buffer-matches-highlighting visits all matches and highlights them; > 2. buffer-matches-counting visits all matches but doesn't highlight them > (only counts) That doesn't sound like a big difference, a priori. Can't you just have a variable or a function argument that says whether to highlight? > Both need special treatment for possible slowdown in a > large buffer, so for performance reasons we need to add > a new customizable variable like lazy-buffer-max-at-a-time, > separate not to conflict with lazy-highlight-max-at-a-time. > The latter applies to the matches on the screen, the former > to the matches in the full buffer. I see. Sounds like that would be do-able, but I don't know anything about the details. Hope you can/will resolve this sometime soon. Thanks for taking a look.