From: Alan Mackenzie <acm@muc.de>
To: Juri Linkov <juri@linkov.net>
Cc: 17453@debbugs.gnu.org
Subject: bug#17453: Framework extending window functions for Follow Mode (etc.).
Date: Wed, 25 Nov 2015 19:33:01 +0000 [thread overview]
Message-ID: <20151125193301.GI2007@acm.fritz.box> (raw)
In-Reply-To: <87egfmkea0.fsf@mail.linkov.net>
Hello, Juri
It's been nearly a week since your last email. In that time, I tried
one of the approaches (see below) that worked just fine.... except it
wouldn't work with replace.el. I got discouraged by this, and moved
onto other things for a while. Now I'm back.
On Thu, Nov 19, 2015 at 02:45:43AM +0200, Juri Linkov wrote:
> >> 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.
OK.
> >> 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.
The "(sit-for 0)" is absolutely not needed: post-command-hook is indeed
always invoked before Emacs checks for timer expiry; I tried this out.
> > 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.
This is precisely what I tried. It works very well in Isearch.
However, the problem is in replace.el (the replace functionality, not
`occur'): `query-replace', instead of using the Command Loop like
Isearch does, implements its own command loop. This seems suboptimal:
it doesn't invoke post-command-hook (or pre-command-hook) until the
entire replace session is over.
This means the use of `query-replace' whilst Follow Mode is enabled is
not going to work properly, without some radical change in replace.el.
Probably the smallest change would be to invoke new hooks
`pre-replace-command-hook' and `post-replace-command-hook' from
`query-replace''s command loop.
A more satisfying change would be to get rid of `perform-replace' and
use Emacs's command loop the way Isearch does. This would probably not
be all that difficult. Do you know if there's any special reason
`query-replace' implements its own command loop?
What do you think?
[ .... ]
> We need to test the same in all modes that use lazy-highlighting too.
Yes. That's a problem, right now.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2015-11-25 19:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20151105192905.GA7986@acm.fritz.box>
[not found] ` <CAAdUY-+Myd4q=9JkS4Pe6gWDKSHNNoZ+jNxm=S_1dSD9np7uRA@mail.gmail.com>
[not found] ` <20151107182420.GA1774@acm.fritz.box>
[not found] ` <871tc18oai.fsf@mail.linkov.net>
[not found] ` <20151108002955.GC1774@acm.fritz.box>
2015-11-09 0:50 ` bug#17453: Framework extending window functions for Follow Mode (etc.) Juri Linkov
[not found] ` <8737wgou4z.fsf@mail.linkov.net>
2015-11-09 15:41 ` Alan Mackenzie
[not found] ` <20151109154124.GC2284@acm.fritz.box>
2015-11-10 0:51 ` 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
2015-11-25 19:33 ` Alan Mackenzie [this message]
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
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=20151125193301.GI2007@acm.fritz.box \
--to=acm@muc.de \
--cc=17453@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).