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: Sat, 20 Oct 2018 16:09:29 -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> <875zxwjlke.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 1540076896 17673 195.159.176.226 (20 Oct 2018 23:08:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 23:08:16 +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 Sun Oct 21 01:08:11 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 1gE0Lq-0004QM-7y for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Oct 2018 01:08:10 +0200 Original-Received: from localhost ([::1]:56858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE0Nw-00061m-JV for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Oct 2018 19:10:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gE0Nk-0005xi-3P for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 19:10:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gE0Ne-0005q6-Rj for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 19:10:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57571) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gE0Ne-0005pu-Nj for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 19:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gE0Ne-0002aH-CP for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 19:10: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: Sat, 20 Oct 2018 23:10: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.15400769809900 (code B ref 29360); Sat, 20 Oct 2018 23:10:02 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 20 Oct 2018 23:09:40 +0000 Original-Received: from localhost ([127.0.0.1]:33596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE0NI-0002Zb-3b for submit@debbugs.gnu.org; Sat, 20 Oct 2018 19:09:40 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:55612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gE0NF-0002ZO-Qv for 29360@debbugs.gnu.org; Sat, 20 Oct 2018 19:09:38 -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 w9KN9VH0125875; Sat, 20 Oct 2018 23:09:31 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=oxPIWv0JZCAuYCO7YAB2GSkrjcFgnY7ORYniychoiv0=; b=w+CSJudazvqBGFvhjYs74viZYauz8JNI7ZFP5vtRSWPMnCeOAM9ur576SRddQ2nMVoFR SkwT6KZV3I41JabbUO5n9UsK45w2mjBbqIpwnSwsceQlCPZchPTh9hUbEWPNRbHpqqAF ikotTQE1CVJafxqL6NPJ4RA4Kq46ot+qtWl3BlG1yZvzuCtuPcGsW7GEo5L/MG5ZzyKw Ye23m9Z9T0Ijh5wL4sYFOrErG7mVrPBbFPaRQkxvA5iHD9ywM4tLSg2CtuoDdypiEsN+ Z0n01y71STdyDrBTn51x0YGQ6+k0UOJemrdzwx2Zq0bvJDfpF+jUAYu/qlkJwH+ejb31 AQ== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2n7vaphga5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 23:09:31 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9KN9Uli003959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Oct 2018 23:09:30 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9KN9UE6011590; Sat, 20 Oct 2018 23:09:30 GMT In-Reply-To: <875zxwjlke.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=9052 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-1810200215 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:151474 Archived-At: > The biggest obstacle is this - currently the traversal order of > visiting matches to lazy-highlight is the following: >=20 > 1. start from the current match forward to the bottom of the window; >=20 > 2. wrap from the bottom to the top of the window; >=20 > 3. start from the top of the window down to the current match. >=20 > Visually you can observe how the current algorithm works by setting: >=20 > (setq lazy-highlight-max-at-a-time 1 > lazy-highlight-initial-delay 1 > lazy-highlight-interval 1) >=20 > This works well when matches are highlighted only on the screen. >=20 > But when boundaries will be extended from the window to the full buffer, > the problem of performance creeps in. Lazy-highlighting will work > in the following order: >=20 > 1. start from the current match forward to the end of the buffer; >=20 > 2. wrap from the end to the beginning of the buffer; >=20 > 3. start from the beginning of the buffer down to the current match. >=20 > The problem is that matches in the upper part of the window might be > highlighted too late - only when all matches in the full buffer > are highlighted, and most of these matches likely will be outside > of the displayed part of the buffer in the window. >=20 > IOW, highlighting of the matches above the current match will be delayed > until all other matches in the whole buffer will get a highlighting > overlay. >=20 > Do you think we should change the algorithm and adapt it to highlighting > of the buffer? Maybe we should first highlight matches on the bottom > and the top part of the window before going to highlight matches in > other parts of the buffer that are not visible on the screen? Thanks for the explanation - very clear. I don't have any brilliant insight into this. I'd imagine that most uses of full-buffer highlighting are either: 1. On relatively small buffers, just for convenience of getting it all done at once (i.e., non-lazy). 2. On any size buffer, for some other purpose than just Isearch. IOW, use Isearch as a UI to get parts of a buffer highlighted (and so propertized), for other purposes than just Isearch. I'm not sure that #1 is a real use case. If it is then it's anyway not problematic for the problem you mention - by definition. It may be that for many of the #2 use cases immediate response for the Isearch part is not that important. (Dunno.) In any case, yes, your suggestion of first doing what we do now (highlight the immediate area, using the current algorith), and then following that with highlighting the rest of the buffer, could be a good idea. Dunno how much that might change the existing code. Another possibility (?) is that for some of the #2 use cases it might even be enough to highlight the rest of the buffer when Emacs is idle. Again, dunno whether that option would be important. But if we do that it should be controllable by users and program, I'd think. You likely have better ideas about all this. These are just a few thoughts that came to mind now. (BTW, I already sometimes see Isearch paint the lazy-highlighting slowly, eventually coming down from the top of the window. Not sure what the circumstances are in which I see that sometimes. Probably when matching takes longer for some reason.)