From: Juri Linkov <juri@linkov.net>
To: Alan Mackenzie <acm@muc.de>
Cc: 17453@debbugs.gnu.org
Subject: bug#17453: Framework extending window functions for Follow Mode (etc.).
Date: Thu, 19 Nov 2015 02:45:43 +0200 [thread overview]
Message-ID: <87egfmkea0.fsf@mail.linkov.net> (raw)
In-Reply-To: <20151118175814.GA1690@acm.fritz.box> (Alan Mackenzie's message of "Wed, 18 Nov 2015 17:58:14 +0000")
>> For consistency with other related names it could have the same prefix, e.g.
>> "window-group-recenter".
>
> Or even "recenter-window-group", since "window-group" isn't strictly a
> prefix in a lot of the other cases anyway.
Maybe "recenter-window-group" in the sense of "recenter a window in the
window group" as opposed to "window-group-recenter" in the sense of
"recenter the whole window group"?
>> Another thing that disturbs me is moving lazy-highlighting checks
>> to a new function isearch-lazy-highlight-maybe-new-loop.
>
> What disturbs you about this change in particular?
The same consequences you mentioned earlier: various time periods
of lazy-highlighting staying active.
>> What do you think about moving only window-checking into new function
>> i.e. only checks for window-start/window-end/etc that need (sit-for 0)
>> and leaving other checks in isearch-lazy-highlight-new-loop?
>
> Actually, I think that "(sit-for 0)" isn't needed - I left it in to deal
> with isearch-lazy-highlight-initial-delay being set to 0, thinking that
> Follow Mode's post-command-hook might "not have had time" to run. But
> surely post-command-hook will be called before checking timers. I'll
> need to look at the source code (probably keyboard.c) to be absolutely
> sure of this.
>
> I don't think splitting the checks between
> isearch-lazy-highlight-new-loop (in the command loop) and a function
> triggered by a timer is a good idea. I tried it out, and it kind of
> jars when the lazy highlighting sometimes stays 0.25s, sometimes goes
> instantly. How about maybe ...
>
> How about maybe putting the test for new highlighting in Isearch's
> post-command-hook (and using the APPEND argument of `add-hook' to make
> sure Isearch's post-hook-function comes after Follow Modes's)? That
> way, all the lazy h. would be removed immediately after the command, as
> at present.
You could try to append a new follow+isearch specific hook
to post-command-hook in follow.el, if this helps.
>> Would this help to avoid new problems such as un-highlighting
>> postponed until the timer fires?
>
> Is this actually a problem? I played with Emacs a little with that
> un-highlighting strategy, and didn't find it any more disturbing than
> the 0.25s gap between old highlighting going and new highlighting
> arriving.
We need to test the same in all modes that use lazy-highlighting too.
next prev parent reply other threads:[~2015-11-19 0:45 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 19:29 Framework extending window functions for Follow Mode (etc.) Alan Mackenzie
2015-11-05 19:36 ` John Wiegley
2015-11-05 20:00 ` Alan Mackenzie
2015-11-07 13:07 ` Alan Mackenzie
2015-11-09 22:30 ` John Wiegley
2015-11-10 11:27 ` Alan Mackenzie
2015-11-10 13:13 ` Alan Mackenzie
2015-11-10 15:20 ` John Wiegley
2015-11-10 22:29 ` John Wiegley
2015-11-11 0:30 ` Alan Mackenzie
2015-11-11 0:34 ` John Wiegley
2015-11-11 16:15 ` Alan Mackenzie
2015-11-11 16:50 ` John Wiegley
2015-11-11 17:15 ` Comms and building Emacs. [Re: Framework extending window functions for Follow Mode (etc.).] Alan Mackenzie
2015-11-11 17:58 ` Alan Mackenzie
2015-11-07 13:26 ` Framework extending window functions for Follow Mode (etc.) martin rudalics
2015-11-07 13:57 ` Alan Mackenzie
2015-11-07 15:18 ` martin rudalics
2015-11-07 16:12 ` Alan Mackenzie
2015-11-07 17:07 ` martin rudalics
2015-11-07 18:55 ` Alan Mackenzie
2015-11-08 9:22 ` martin rudalics
2015-11-08 12:13 ` Alan Mackenzie
2015-11-08 18:10 ` martin rudalics
2015-11-08 19:57 ` Alan Mackenzie
2015-11-09 8:25 ` martin rudalics
2015-11-09 17:03 ` Alan Mackenzie
2015-11-07 17:54 ` Artur Malabarba
2015-11-07 18:24 ` Alan Mackenzie
2015-11-07 21:58 ` Juri Linkov
2015-11-08 0:29 ` Alan Mackenzie
2015-11-08 9:23 ` martin rudalics
2015-11-09 0:50 ` Juri Linkov
2015-11-09 15:41 ` bug#17453: " Alan Mackenzie
2015-11-09 15:41 ` Alan Mackenzie
2015-11-10 0:51 ` bug#17453: " Juri Linkov
2015-11-10 11:08 ` Alan Mackenzie
2015-11-11 0:12 ` Juri Linkov
2015-11-11 16:19 ` Alan Mackenzie
2015-11-12 0:52 ` Juri Linkov
2015-11-12 8:22 ` martin rudalics
2015-11-12 20:14 ` Juri Linkov
2015-11-17 22:55 ` Alan Mackenzie
2015-11-18 0:38 ` Juri Linkov
2015-11-18 17:58 ` Alan Mackenzie
2015-11-18 21:28 ` Alan Mackenzie
2015-11-19 0:45 ` Juri Linkov [this message]
2015-11-25 19:33 ` Alan Mackenzie
2015-11-26 23:03 ` Juri Linkov
2015-11-30 20:37 ` Alan Mackenzie
2015-12-01 0:07 ` Juri Linkov
2015-12-05 16:40 ` Alan Mackenzie
2015-12-05 23:06 ` Juri Linkov
2015-12-07 19:15 ` Alan Mackenzie
2015-12-08 0:42 ` Juri Linkov
2015-11-12 22:15 ` Alan Mackenzie
2015-11-09 0:50 ` 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=87egfmkea0.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=17453@debbugs.gnu.org \
--cc=acm@muc.de \
/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.