From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Date: Sat, 29 Aug 2015 07:42:42 -0700 (PDT) Message-ID: <6ef534bf-ecf3-48a4-9414-46de26d911c7@default> References: <<9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <<7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <<83lhcv4wp4.fsf@gnu.org>> <<56e13714-27a7-47f9-93df-299b4a25457d@default>> <<87si73dsjt.fsf@mail.linkov.net>> <> <<83pp26373z.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440859406 25944 80.91.229.3 (29 Aug 2015 14:43:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Aug 2015 14:43:26 +0000 (UTC) Cc: juri@linkov.net, 21092@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 29 16:43:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVhLa-000467-VH for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Aug 2015 16:43:11 +0200 Original-Received: from localhost ([::1]:52890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVhLa-0003gW-4n for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Aug 2015 10:43:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVhLT-0003f0-7y for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2015 10:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVhLS-0004pu-57 for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2015 10:43:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVhLS-0004pq-1J for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2015 10:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVhLR-0001Nm-NV for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2015 10:43:01 -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, 29 Aug 2015 14:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21092 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21092-submit@debbugs.gnu.org id=B21092.14408593715298 (code B ref 21092); Sat, 29 Aug 2015 14:43:01 +0000 Original-Received: (at 21092) by debbugs.gnu.org; 29 Aug 2015 14:42:51 +0000 Original-Received: from localhost ([127.0.0.1]:42194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVhLG-0001NO-D4 for submit@debbugs.gnu.org; Sat, 29 Aug 2015 10:42:50 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:20063) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVhLE-0001NF-DS for 21092@debbugs.gnu.org; Sat, 29 Aug 2015 10:42:48 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7TEgk6T028720 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Aug 2015 14:42:47 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t7TEgjc6017449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Aug 2015 14:42:46 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t7TEgjm1026329; Sat, 29 Aug 2015 14:42:45 GMT In-Reply-To: <<83pp26373z.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105945 Archived-At: > > Please see the simple patch I sent, which I think takes care of this. >=20 > If we are going to extend highlighting beyond the displayed portion of > the buffer, then your proposed patch needs more work, IMO. AFAIU, > with your patch, setting lazy-highlight-max-at-a-time to, say, 2000, > will still limit the highlighting to the displayed portion, which > makes little sense to me, as the probability of finding more than 2000 > matches in a single window-full is practically zero, and so the user's > intent will not be honored (and the doc string will still be > misleading). Yes. As I said, more than once, the patch I submitted fixes the bug only "for a nil value". And I added: Feel free to adjust the fix. Or to extend it to also take a numeric value into account. But I will be happy if it is fixed at least for nil. My immediate need, for which there is an easy, quick fix, is to make the option work for nil. I certainly agree that it would be good to also make it work for large numeric values - which is why I invited such an additional fix. That will be useful. > Instead, I suggest to use a special non-nil value, e.g. zero or -1, to > indicate a limit to the current window's end, and treat any other > value literally, disregarding the window limits. (This will need to > be reflected in the documentation, of course.) That special value > should IMO be the default. Or maybe introduce a separate predicate > option for whether to limit to window start and end. That sounds OK to me. Except that you did not explicitly mention nil. Do you mean, by treat it literally, that it should behave for nil as it is advertised now: no limit at all? If so then I agree. IOW, I would like nil to behave as advertised: no limit. This is the use case that prompted me to file the bug and look for a solution. > Yes, this would be a backward-incompatible change, but I don't think > the difference will matter too much in most use cases, especially with > the default value of lazy-highlight-cleanup. Because this has never worked before for areas beyond the window, it does not really present backward compatibility problems. Unless you are considering someone who has set the value to 99999999 and continues to expect highlighting to be limited to the window. > Btw, another issue that arises in this regard is whether to highlight > beyond the screen only in the direction of the search (which AFAICS is > what your proposed patch does) or in both directions, especially when > the value of lazy-highlight-max-at-a-time is nil. Good point. My patch is not good enough here, though it is enough to temporarily switch directions (e.g., from C-s to C-r) to work around this incompleteness. That is the first (next) thing to do, I think: fix things completely for nil, so that it highlights all search hits (both directions). I will take another look when I get a chance, if no one beats me to it. That would also give users a real difference in behavior between a very large number and nil, which is good. There should be a way, which a very large number would provide, of getting a no-limit behavior for only the current search direction. (My patch currently does this (for nil), but that is not the behavior nil should provide, IMO.) I appreciate your interest in this and hope that we do get it fixed.