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: Fri, 28 Aug 2015 08:19:35 -0700 (PDT) Message-ID: <56e13714-27a7-47f9-93df-299b4a25457d@default> References: <<9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>> <<7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>> <<83lhcv4wp4.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 1440775226 23126 80.91.229.3 (28 Aug 2015 15:20:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 15:20:26 +0000 (UTC) Cc: 21092@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 17:20:13 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 1ZVLRs-0001WF-LH for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 17:20:12 +0200 Original-Received: from localhost ([::1]:48394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLRr-00023P-RM for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 11:20:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLRn-00020w-38 for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:20:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVLRi-0001nH-RV for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLRi-0001mi-Oh for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZVLRi-0003bu-3Q for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:20: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: Fri, 28 Aug 2015 15:20: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.144077518213850 (code B ref 21092); Fri, 28 Aug 2015 15:20:01 +0000 Original-Received: (at 21092) by debbugs.gnu.org; 28 Aug 2015 15:19:42 +0000 Original-Received: from localhost ([127.0.0.1]:41583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLRO-0003bJ-0W for submit@debbugs.gnu.org; Fri, 28 Aug 2015 11:19:42 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40239) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZVLRL-0003bA-A4 for 21092@debbugs.gnu.org; Fri, 28 Aug 2015 11:19:40 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t7SFJbDo009733 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Aug 2015 15:19:38 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 t7SFJbPs024985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 15:19:37 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 t7SFJavH024590; Fri, 28 Aug 2015 15:19:37 GMT In-Reply-To: <<83lhcv4wp4.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:105919 Archived-At: > > > 1. emacs -Q > > > 2. Visit a file - anything other than a tiny one will do. > > > 3. Use `customize-option' to set `lazy-highlight-cleanup' to nil > > > and set `lazy-highlight-max-at-a-time' to nil. > > > 4. Search once for a simple string that occurs multiple times through= out > > > the buffer - e.g., `C-s the RET`. > > > 5. Scroll down to see that the matches were not highlighted throughou= t > > > the buffer. `lazy-highlight-max-at-a-time' does not work as > > > advertised. >=20 > What do you mean by "scroll down" in step 5 above? Scroll down how? C-v or whatever. (Yes, this will exit Isearch,) > Scrolling (as any other command that exits I-search) removes all > highlighting, at least by default. No, it does not. Not if `lazy-highlight-cleanup' is nil - see step 3. That's the point of that option, and of this bug report. > And "all matches" in the > variable's doc string means "all matches shown on the screen", How could that be? What's the point of the option value of nil - or even a large value - in that case? And why would we bother to warn that a large (let alone a nil) value can make things slow, if highlighting is always limited to what is visible "on the screen"? How big a screen would someone have to have, to make any consideration of performance important, if nil is _supposed_ to highlight only all matches "on the screen"? Where do you get your interpretation of "all matches"? From the display-engine code, I guess, but certainly not from the doc or the Customize UI, which says just "All". All matches means all matches; it does not mean all matches that fit some unmentioned criterion. > as the display engine never does anything beyond the displayed > portion (that's a simplification, but it will do for the purposes > of this discussion). That description of the display-engine _implementation_, which I don't doubt, does not jibe with the description of the option. And as the description is quite deliberate about the possibilities and behavior of both a LARGE value and a nil value, and about the consequent risks to performance, it would seem that the _design_ of this feature does not fit the display-engine implementation. Am I missing something else? What's the point of such a design (and its consequent doc), if it could _never be realized_ because of display-engine limitations? (I don't doubt the display-engine design or implementation. The question is about how this design could possibly work, given the display engine as you say it is.) Something else puzzles me. I did not have the impression that there was such a hard-and-fast display limitation. Am I mistaken that we have no problem forcing the display engine to font-lock fontify a whole buffer, regardless of size? If that is possible (I am thinking it is possible, but I could be wrong) then why would it not also be possible to put lazy-highlight highlighting on a whole buffer, regardless of size? And I can call a homemade function that highlights stuff throughout a LARGE buffer, whether using font-lock or otherwise. No problem, AFAICS. Wrt the actual behavior I see: a nil value seems, indeed to have no effect beyond the text that has already been shown. That's really too bad. (And lazy highlighting, beyond just highlighting, also computes all search matches, which can be useful. But perhaps you will say that it computes only all matches on the screen?) I do hope that someone takes a close look at this and you don't just dismiss it. AFAICT, it is possible to highlight text throughout a buffer, even a VERY large one, and using either overlays or text properties. IOW, I don't understand - I don't think I see the display-engine limitation you seem to be saying is in place. IIUC, a lot has changed since lazy highlighting and these options were first introduced - jit-lock, etc. Perhaps this worked at one time, and a regression was introduced since then? (No, I don't see that myself - the same bug is in Emacs 22.3.) Or are you absolutely convinced that this could never have worked, because of the way the display engine works? If so then I'm quite disappointed, but in that case please at least correct the doc and the Customize UI, to make clear that the value (numeric or nil) has no effect beyond what is/has been shown on the screen - that it is not at all about highlighting "all matches". And given that Lisp code apparently _can_ highlight a whole, large buffer (AFAICT), if you have any tips on how I might make this work, myself, for Isearch lazy highlighting, please pass them along.