From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: 21092@debbugs.gnu.org
Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work
Date: Tue, 1 Sep 2015 17:07:11 -0700 (PDT) [thread overview]
Message-ID: <e6087774-d809-4b4e-9343-c7937f170ef3@default> (raw)
In-Reply-To: <87mvx5oim0.fsf@mail.linkov.net>
> I tried to find a useful application for this feature, and finally found.
Great. What's the application?
> > Whole buffer OR rest-of-buffer forward or backward. Au choix.
> > Both behaviors are useful.
>
> Since you can scroll up or down, highlighting the whole buffer is
> unavoidable.
I don't understand. Can you elaborate a bit? With the patch I
sent it seemed to be avoided. When searching forward, the only
matches before point that got highlighted were those in the window.
IIUC, this is not important to me, but I would like to understand.
> > Not clear why you want a separate option for this. It cannot be
> > used in combination with `lazy-highlight-max-at-a-time', can it?
>
> Of course, it is useful in combination with ‘lazy-highlight-max-at-a-time’
> that can define the incrementality (how many steps to do) regardless
> whether highlighting the whole buffer or only matches on the screen.
I see now that I misunderstood what was meant by "at a time" in
"max-at-a-time".
I was thinking that it referred to all of the highlighting for
a given input (e.g. after an input change). Instead, it refers
to one invocation of `isearch-lazy-highlight-update', whose loop
runs only `lazy-highlight-max-at-a-time' iterations. And `*-update'
can get reinvoked by the timer to complete the highlighting for the
input.
> > A second question concerns how to control whether this acts
> > only in the current search direction or in both directions.
>
> We can highlight only in the search direction because regexp
> search might match different results depending on direction.
> So you need to switch directions with ‘C-r’ to re-highlight
> the buffer.
You just said that "highlighting the whole buffer is unavoidable",
so I am a bit confused. Now you seem to be saying that we can
highlight only in one direction at a time. Maybe you could
elaborate a bit here?
> > For exmaple, I might want a toggle between max=10 and
> > whole-buffer.
>
> This will be possible with two separate variables:
> the existing ‘lazy-highlight-max-at-a-time’
> to toggle between max=10 and max=nil
> and the new ‘lazy-highlight-buffer’
> to toggle between whole-buffer and screen-only
> implemented by this small patch:
I misunderstood max-at-a-time. So maybe the doc for it needs
clarifying wrt what is meant by at a time etc.
The doc and defcustom need fixing anyway, for the confusion
over the meaning of "all matches" etc., discussed previously.
Anyway, your patch looks good. It is essentially the same
as mine, but using `lazy-highlight-buffer' instead of a nil
value of `lazy-highlight-max-at-a-time'. I understand now
that they have different purposes.
The difference is that I did not change the occurrences of
`window-(start|end)' in `isearch-lazy-highlight-new-loop'.
I wasn't sure it was needed (not fully understanding it),
and I didn't notice a problem without it. But I'm glad that
you, knowing more, made the same change there as well.
Thx - Drew
next prev parent reply other threads:[~2015-09-02 0:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<9e1b9e19-6a1e-4241-a3e6-2876509e1423@default>
[not found] ` <<7245a30d-355a-425e-b19b-1c9ecc5e94e3@default>
[not found] ` <<83lhcv4wp4.fsf@gnu.org>
2015-08-28 15:19 ` bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work Drew Adams
2015-08-28 15:46 ` Eli Zaretskii
2015-08-28 21:14 ` Juri Linkov
2015-08-28 21:43 ` Drew Adams
2015-08-29 7:07 ` Eli Zaretskii
[not found] ` <<56e13714-27a7-47f9-93df-299b4a25457d@default>
[not found] ` <<83wpwf2z6m.fsf@gnu.org>
2015-08-28 15:59 ` Drew Adams
2015-08-28 16:03 ` Eli Zaretskii
[not found] ` <<e4ec2bca-0db5-43ba-a100-e99601d39e4c@default>
[not found] ` <<83twrj2ye6.fsf@gnu.org>
2015-08-28 16:15 ` Drew Adams
2015-08-28 16:44 ` Drew Adams
2015-08-28 16:59 ` Drew Adams
[not found] ` <<87si73dsjt.fsf@mail.linkov.net>
[not found] ` <<b0d4a886-77ae-4b58-b1b8-3b15999f5052@default>
[not found] ` <<83pp26373z.fsf@gnu.org>
2015-08-29 14:42 ` Drew Adams
2015-08-29 21:10 ` Juri Linkov
2015-08-30 2:40 ` Eli Zaretskii
2015-08-30 5:39 ` Drew Adams
2015-08-30 20:58 ` Juri Linkov
2015-08-30 22:39 ` Drew Adams
2015-08-31 20:01 ` Juri Linkov
2015-08-31 21:35 ` Drew Adams
2015-09-01 22:55 ` Juri Linkov
2015-09-02 0:07 ` Drew Adams [this message]
2015-09-02 22:40 ` Juri Linkov
2015-12-24 0:47 ` Juri Linkov
2017-02-22 0:16 ` Juri Linkov
2015-07-19 13:36 Drew Adams
2015-08-27 20:29 ` Drew Adams
2015-08-28 8:57 ` Eli Zaretskii
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=e6087774-d809-4b4e-9343-c7937f170ef3@default \
--to=drew.adams@oracle.com \
--cc=21092@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).