From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Date: Sun, 21 Oct 2018 01:12:49 +0300 Organization: LINKOV.NET Message-ID: <875zxwjlke.fsf@mail.linkov.net> 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 X-Trace: blaine.gmane.org 1540074946 16745 195.159.176.226 (20 Oct 2018 22:35:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Oct 2018 22:35:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 29360@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 21 00:35:41 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 1gDzqO-0004EU-NH for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Oct 2018 00:35:41 +0200 Original-Received: from localhost ([::1]:56797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDzsV-00069E-Ac for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Oct 2018 18:37:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDzrm-0005qB-Gl for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 18:37:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDzri-0007nL-8o for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 18:37:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57559) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDzri-0007nF-2o for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 18:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gDzrh-0001mw-V0 for bug-gnu-emacs@gnu.org; Sat, 20 Oct 2018 18:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Oct 2018 22:37: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.15400749836829 (code B ref 29360); Sat, 20 Oct 2018 22:37:01 +0000 Original-Received: (at 29360) by debbugs.gnu.org; 20 Oct 2018 22:36:23 +0000 Original-Received: from localhost ([127.0.0.1]:33584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzr5-0001m5-28 for submit@debbugs.gnu.org; Sat, 20 Oct 2018 18:36:23 -0400 Original-Received: from pop.dreamhost.com ([64.90.62.162]:42410 helo=pdx1-sub0-mail-a10.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDzr3-0001lx-B9 for 29360@debbugs.gnu.org; Sat, 20 Oct 2018 18:36:21 -0400 Original-Received: from pdx1-sub0-mail-a10.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTP id C8A6580381; Sat, 20 Oct 2018 15:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=256dTsZHYbx4gJ/WLbimwp/Sd3U=; b= rsjkzkdiHrwkeC5y+yEvC7JFh4IMINNEjUWeUoQIZuPWKxA8denrvn4dY9JKCJRc Lv4bpCxzO2yDcw4qu1pX/GS7k5aSnizVnyCT7XeMuFHiNGKg4KcAL8HvlL/rHVfe VFPJGc+Wxrco9BdbMPSF0GlAJT8Rx202v3dyjsXi9nE= Original-Received: from mail.jurta.org (m91-129-96-249.cust.tele2.ee [91.129.96.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 1547D8037B; Sat, 20 Oct 2018 15:36:18 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a10 In-Reply-To: (Drew Adams's message of "Thu, 18 Oct 2018 16:25:03 -0700 (PDT)") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrfeekgddujeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucffohhmrghinhepghhnuhdrohhrghenucfkphepledurdduvdelrdeliedrvdegleenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrvdegledprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd 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:151473 Archived-At: >> Actually, a full-buffer lazy-highlighting possibility already exists: >> >> (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-group-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. ;-)) Sorry, I meant isearch-mode-hook, not isearch-mode-end-hook. But this detail is not important for properly implementing this feature. >> 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? It's here: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c5e66afa88d6ff8ad5c42318d85188ed477e7db2 >> 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. The biggest obstacle is this - currently the traversal order of visiting matches to lazy-highlight is the following: 1. start from the current match forward to the bottom of the window; 2. wrap from the bottom to the top of the window; 3. start from the top of the window down to the current match. Visually you can observe how the current algorithm works by setting: (setq lazy-highlight-max-at-a-time 1 lazy-highlight-initial-delay 1 lazy-highlight-interval 1) This works well when matches are highlighted only on the screen. 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: 1. start from the current match forward to the end of the buffer; 2. wrap from the end to the beginning of the buffer; 3. start from the beginning of the buffer down to the current match. 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. 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. 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?