From: Juri Linkov <juri@linkov.net>
To: Drew Adams <drew.adams@oracle.com>
Cc: 21092@debbugs.gnu.org
Subject: bug#21092: 25.0.50; Option `lazy-highlight-max-at-a-time' does not work
Date: Mon, 31 Aug 2015 23:01:34 +0300 [thread overview]
Message-ID: <87y4grw7kx.fsf@mail.linkov.net> (raw)
In-Reply-To: <7d3e51a1-945f-497e-8af1-449cd4151ca1@default> (Drew Adams's message of "Sun, 30 Aug 2015 15:39:45 -0700 (PDT)")
> You clearly do not want this done.
Not at all. I only disagree that it's a bug.
‘lazy-highlight-max-at-a-time’ is just an optimization variable
along with ‘lazy-highlight-initial-delay’, ‘lazy-highlight-interval’
that users might want to tweak to improve performance where nil of
‘lazy-highlight-max-at-a-time’ allows highlighting in one loop
that avoids delays on fast processors (it makes sense to change
its default value to nil to match the modern hardware).
A new feature to highlight the whole buffer would be useful as well
to reduce flickering during Isearch. Currently when e.g. scrolling
by one line lazy-highlight clears all matches on the screen, and
re-highlights them with an additional line taken into account.
That's because lazy-highlight is non-incremental.
Highlighting the whole buffer could fix this visual effect.
So unlike the current screen-limited lazy-highlighting that reacts
to window-start/window-end changes, once whole-buffer lazy-highlighting
finds all matches in the buffer it doesn't need to re-highlight them
during Isearch navigation.
A new option could be named e.g. (defcustom lazy-highlight-buffer nil)
Again, its default value is depending on the average hardware.
While I believe that highlighting all matches on the screen
is suitable for most users, I'm not sure about highlighting
all matches in a (possibly large) buffer in one loop.
> You have not wanted a boatload of features,
Yes, I resist a bloatload of features, but I'm happy with adding
features that solve a complex usability problem in a simple way.
> whether it's searching within the active region (not needed,
> since a user can always narrow the buffer);
Because it's more useful to extend the bounds of the active region
using Isearch.
> search within text- or overlay-property zones;
There is an unfinished feature request bug#15245.
> on-demand replacement of search hits during search
Can you find a bug# for this?
> Please at least fix the doc so that it matches what the
> code does, whether or not that matches what the original
> intention was.
Then the docstring could point to the new option ‘lazy-highlight-buffer’.
next prev parent reply other threads:[~2015-08-31 20:01 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 [this message]
2015-08-31 21:35 ` Drew Adams
2015-09-01 22:55 ` Juri Linkov
2015-09-02 0:07 ` Drew Adams
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4grw7kx.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=21092@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/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.