From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: 29360@debbugs.gnu.org
Subject: bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight'
Date: Thu, 18 Oct 2018 16:25:03 -0700 (PDT) [thread overview]
Message-ID: <e6f0da60-785e-42d7-a5be-52f6fce359ff@default> (raw)
In-Reply-To: <87va5yhpaq.fsf@mail.linkov.net>
> > It would really be good if this enhancement were made - for the
> > reasons I gave in bug #21092, and for other reasons. You asked me
> > (in bug #21092) to file this bug if I thought we needed such a
> > full-buffer possibility. This enhancement request was the result.
>
> 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. ;-))
> But I agree that more straightforward customization would be better
> with a clear value of the customizable variable.
Thank you. Will you please implement that when you get a chance?
> > Did you not have a patch that took care of this? IIRC you then found
> > a problem with it wrt `follow-mode', but I thought you had a solution
> > for that too. (I thought the latter solution was provided by Artur's
> > `all-windows' value for `isearch-lazy-highlight' etc., which was added.)
>
> 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?
> > What's the status of this feature? Can we add it to Emacs now?
> > I hope so.
>
> The reason why it's not yet finished is because it was unclear how to
> integrate it with another similar feature of matches-counting (that counts
> the number of matches in the full buffer). The reasoning is the following:
> both features require using the same loop in isearch-lazy-highlight
> extending it to operate on the full buffer. I know you will argue that
> these are unrelated features and should be treated separately.
I won't argue any such thing, as I know nothing about this stuff. ;-)
> But implementation-wise they have only one difference:
>
> 1. buffer-matches-highlighting visits all matches and highlights them;
> 2. buffer-matches-counting visits all matches but doesn't highlight them
> (only counts)
That doesn't sound like a big difference, a priori. Can't you just
have a variable or a function argument that says whether to
highlight?
> 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.
Thanks for taking a look.
next prev parent reply other threads:[~2018-10-18 23:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-19 19:05 bug#29360: 26.0; Add full-buffer choice for `isearch-lazy-highlight' Drew Adams
2017-11-20 20:53 ` Juri Linkov
2017-11-20 22:40 ` Drew Adams
2017-11-23 21:49 ` Juri Linkov
2017-11-23 23:53 ` Drew Adams
2018-10-18 5:47 ` Drew Adams
2018-10-18 22:18 ` Juri Linkov
2018-10-18 23:25 ` Drew Adams [this message]
2018-10-20 17:10 ` Drew Adams
2018-10-20 22:12 ` Juri Linkov
2018-10-20 23:09 ` Drew Adams
2018-10-21 19:06 ` Juri Linkov
2018-10-22 3:33 ` Drew Adams
2018-10-23 22:05 ` Juri Linkov
2018-10-23 22:51 ` Drew Adams
2018-10-24 23:11 ` Juri Linkov
2018-10-25 0:28 ` Drew Adams
2018-10-27 20:28 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6f0da60-785e-42d7-a5be-52f6fce359ff@default \
--to=drew.adams@oracle.com \
--cc=29360@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.