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: Sun, 21 Oct 2018 20:33:35 -0700 (PDT) Message-ID: <76121a16-e057-4aa7-9a5a-1f09cc221d7c@default> 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> <87woqbglvb.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 1540179608 22201 195.159.176.226 (22 Oct 2018 03:40:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Oct 2018 03:40:08 +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 Oct 22 05:40:03 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 1gER4V-0005ed-8v for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Oct 2018 05:40:03 +0200 Original-Received: from localhost ([::1]:32817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gER6b-0005Dg-De for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Oct 2018 23:42:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gER6Q-000597-Ah for bug-gnu-emacs@gnu.org; Sun, 21 Oct 2018 23:42:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEQyg-0001wT-9V for bug-gnu-emacs@gnu.org; Sun, 21 Oct 2018 23:34:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58948) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gEQyg-0001wP-4w for bug-gnu-emacs@gnu.org; Sun, 21 Oct 2018 23:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gEQyg-0007A9-0X for bug-gnu-emacs@gnu.org; Sun, 21 Oct 2018 23:34: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: Mon, 22 Oct 2018 03:34: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.154017923127516 (code B ref 29360); Mon, 22 Oct 2018 03:34:01 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 22 Oct 2018 03:33:51 +0000 Original-Received: from localhost ([127.0.0.1]:34973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEQyU-00079k-QL for submit@debbugs.gnu.org; Sun, 21 Oct 2018 23:33:51 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:45640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEQyS-00079X-NG for 29360@debbugs.gnu.org; Sun, 21 Oct 2018 23:33:49 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9M3XYec167988; Mon, 22 Oct 2018 03:33:42 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=/QrRIaKjW6jPvYzDkCjrVPKBkLAZRPMBDe6f6YJlGOg=; b=VRjC+QcobnT+pFVzEEkuf50Is1vZHThJvQcTMjKWUlIg5MC7ULa/9SRXFwcMc06SbgXt 4PcHPBMeninC7cXOBBPCzV4hbVuw7x+JTYD8lR5S79vTTHoJdMUQgrOQ3YgXU45SUtWj OC19AcR9LgSxYK78Lf/39G6+9pUUpqE5w4FUR8uvaWpRAuXEY9wQVZSPKZwkSoBORs1c 6/sPtcqfYCwMvmg5kwWL5Or7Kc+77lly8WypA6tRokWzeu6rLyAQ8jWvOyY2U5waKU/M J3PPTgQ+Z3Gb/6SzitUhoDur/YAUCD3wa2mqAoeJRTWI4kYQnMWIX2zGBixNfAiwbO4O Kw== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2n7ustuxhw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 03:33:42 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9M3Xaj2003364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Oct 2018 03:33:37 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9M3Xa1H003390; Mon, 22 Oct 2018 03:33:36 GMT In-Reply-To: <87woqbglvb.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=9053 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-1810220033 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:151495 Archived-At: > > 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. >=20 > In the patch attached below, a new function isearch-lazy-highlight-buffer= - > update > is a copy of isearch-lazy-highlight-update with some changes specific > to highlighting the full buffer. It seems making a duplicate function > is necessary because adding more full-buffer specific conditions to > the existing function isearch-lazy-highlight-update will make it > unmaintainable. >=20 > Only a part of the function (that highlights the match) is extracted > into a new function isearch-lazy-highlight-match and shared among these > aforementioned two functions. Thanks for doing this. A cursory check tells me it works. One main comment and a couple of minor ones. 1. The main one is to remind you of what I said earlier: > [P]lease also allow also for programmatic use. Code > should be able to bind a variable (non-option, if binding an > option is verboten) to control whether lazy highlighting is > full-buffer. > > That is, I believe that Isearch has several cases where there > are both a user option and a non-option variable to control some > behavior. That should be the case for full-buffer highlighting too. As also stated earlier, I expect that the main use cases will involve using "Isearch as a UI to get parts of a buffer highlighted (and so propertized), for other purposes than just Isearch." Would you please consider adding such non-option variable control? I don't need it for my own code, because I don't hesitate to offer commands that bind user options. But vanilla Emacs feels differently. 2. Please think about changing "on the screen" (it's in a couple places) to something like "currently visible in the window". (Or "currently visible on the screen" if you want this to apply to multiple windows.) This is actually something that's bothered me before, but it becomes more important now that we've introduced the possibility of highlighting "beyond the screen", so to speak. My concern here is that "on the screen" can be misinterpreted as more than just the text that is currently shown. Even talking about the text that is "in" a window is problematic for someone who hasn't gotten acquainted with Emacs jargon. A user can mistakenly think that all of a buffer's text is "in" a window that shows the buffer, even the parts that are not currently shown there. We should try to somehow get across the fact that only text in parts of the buffer that you show by scrolling to it gets highlighted. Yes, there could be some confusion regarding invisible text if we say something like currently "visible" or "shown". But I don't think "on the screen" is clear enough. It's not obvious to a user that there is some text in the buffer that is not "on the screen". Maybe it would be best to explicitly state what's involved, at each place where we speak of "screen" - including perhaps `isearch-allow-scroll'. Perhaps say that unless `isearch-lazy-highlight-buffer' is non-nil lazy highlighting highlights only the parts of the buffer you can currently see (but that other parts already highlighted remain highlighted). Also, as a casual user might well wonder why we have option `isearch-lazy-highlight-buffer', it might be good to mention a use case: you might want to highlight all occurrences and then process all of them programmatically. (And mention option `lazy-highlight-cleanup', for instance.) Dunno how important this is, as most users will neither look at `isearch-lazy-highlight-buffer' nor imagine that they might want to highlight text that they don't yet see. But for a user who does, it could help to give them the idea that they might do something with the highlighted text. 3. Finally, I think that lazy-highlighting the full buffer will typically go hand in hand with keeping the highlighting. That is, non-nil `isearch-lazy-highlight-buffer' will be used with nil `isearch-lazy-highlight-cleanup', and vice versa. It might be useful to make it easy to couple the two. (In my own code, at least, I've added a key that toggles `isearch-lazy-highlight-buffer' and sets `isearch-lazy-highlight-cleanup' to `(not isearch-lazy-highlight-buffer)'. I know that Emacs won't want keys that toggle option values, so I'm not sure what Emacs would want to do to make it easy for a user to couple the two.) 4. Another possible addition might be an indicator somewhere (in the prompt? lighter?) to show that lazy highlighting is in progress. Dunno whether that's needed. It's good that you added the message letting you know when it's done. Thanks again for implementing this feature. I think you can close this bug now. I've played with it a bit, and it seems to work fine. - Drew