[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17453: Framework extending window functions for Follow Mode (etc.).
From: |
Juri Linkov |
Subject: |
bug#17453: Framework extending window functions for Follow Mode (etc.). |
Date: |
Tue, 01 Dec 2015 02:07:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) |
>> The patch in bug#20430 awaits the possibility of helping to fix this
>> problem. It adds a new hook replace-update-post-hook that is like
>> its isearch counterpart hook isearch-update-post-hook is the right way
>> to handle display updates like syncing follow windows, etc.
>
> Does this patch exist, yet?
Yes, you can find the patch in http://debbugs.gnu.org/20430#8
> It bothers me a little that we might be adding hook after hook into
> Emacs, each one for a single special purpose.
Fortunately, a new hook is not for a single special purpose -
it's a general type of hook, requested for different user needs.
> Would it not perhaps be better to call `isearch-update-post-hook' also
> from `perform-replace', since that would be more economical with hooks;
> the meaning of the hook invocation would be "the same" in Isearch and
> `perform-replace' - "hook called after having moved to the next match".
Logically, it makes sense to reuse isearch hooks in query-replace
since query-replace searches for matches like isearch does, but
practically users might have such customizations in .emacs that
would break query-replace in unpredictable ways. This is why
a separate query-replace hook would be much safer.
I see no problem for follow-mode to add follow-post-command-hook
to both hooks.
>> Together with changing the order of calling isearch-update-post-hook
>> and isearch-lazy-highlight-new-loop in isearch-update, adding
>> follow-post-command-hook to isearch-update-post-hook, and adding
>> follow-post-command-hook to replace-update-post-hook to handle
>> follow-mode in query-replace will comprise the least radical change
>> just before the next release.
>
> This sounds like a good idea. Though, again, I think calling
> isearch-update-post-hook from `query-replace' would be better than
> implementing a new hook.
Adding a new hook is just a one-liner, but we have to find the right place
in perform-replace to call it. I think replace-update-pre-hook should be
called before (read-event), and replace-update-post-hook after (read-event).
I'm not yet sure which one is needed for follow-mode to sync windows?
> Would it still be possible to mark `isearch-update-post-hook' as "for
> internal use only", so that we could get rid of it later?
isearch-update-post-hook is a first-class hook added 5 years ago,
so there is no need to remove it.
- bug#17453: Framework extending window functions for Follow Mode (etc.)., (continued)
- bug#17453: Framework extending window functions for Follow Mode (etc.)., martin rudalics, 2015/11/12
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Juri Linkov, 2015/11/12
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/17
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Juri Linkov, 2015/11/17
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/18
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/18
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Juri Linkov, 2015/11/18
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/25
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Juri Linkov, 2015/11/26
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/30
- bug#17453: Framework extending window functions for Follow Mode (etc.).,
Juri Linkov <=
- bug#17453: Framework extending window functions for Follow Mode (etc.)., Alan Mackenzie, 2015/11/12