unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).