[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17453: Isearch doesn't work properly with Follow Mode.
From: |
Stefan Monnier |
Subject: |
bug#17453: Isearch doesn't work properly with Follow Mode. |
Date: |
Sun, 11 May 2014 12:09:38 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
> Follow Mode knows nothing of Isearch.
follow-mode.el doesn't, indeed, but since you're moving some follow mode
code to isearch.el, that means that follow mode (which is now spread
over follow-mode.el and isearch.el) knows something about Isearch.
> The problem the other way round is in Lisp files that themselves play
> with redisplay (including calling `sit-for') and `set-window-start',
> and so on. Between these invocations and the actual redisplay, Follow
> Mode must get a chance to make its adjustments.
There's no doubt that follow mode's task is a tricky one, and I'm
willing to add special support for it. I just want this special support
to be a bit more generic than what you provided.
It shouldn't be too difficult. It's just a matter of refactoring:
change your patch so that on isearch.el's side it only adds some hooks,
which are then set follow-mode.el.
>> IOW we should try harder to come up with more general hooks.
> For what?
So that the same hooks can be used by other code than Isearch, for example.
> Maybe a useful hook here would be `redisplay-hook' where Follow Mode
> could do its stuff more effectively than on `post-command-hook'.
There's pre-redisplay-function, which I think it does get us closer but
is not sufficient yet. And of course, it won't help with things
like "bring-region-into-sight".
>> > @@ -2207,10 +2239,12 @@
>> > together with as much of the search string as will fit; the symbol
>> > `above' if we need to scroll the text downwards; the symbol `below',
>> > if upwards."
>> > - (let ((w-start (window-start))
>> > - (w-end (window-end nil t))
>> > - (w-L1 (save-excursion (move-to-window-line 1) (point)))
>> > - (w-L-1 (save-excursion (move-to-window-line -1) (point)))
>> > + (let ((w-start (isearch-windows-start))
>> > + (w-end (isearch-windows-end nil t))
>> > + (w-L1 (with-selected-window (car isearch-windows)
>> > + (save-excursion (move-to-window-line 1) (point))))
>> > + (w-L-1 (with-selected-window (car (last isearch-windows))
>> > + (save-excursion (move-to-window-line -1) (point))))
>> This isearch-string-out-of-window+isearch-back-into-window business, for
>> example should be generalized to a function along the lines of
>> "bring-region-into-sight". It's not useful only for isearch.
> This seems to be a different bug to the one I reported, and orthogonal
> to it.
What bug? I'm just pointing out that the code you're modifying is more
generally useful and that this generality is a good guide to help us
decide where to put needed hooks.
>> E.g. ediff-next-hunk would also benefit from it.
^^^^^
I meant "diff", sorry. Tho it would also be useful to ediff and smerge-mode
as well, indeed.
> Not necessarily. isearch-back-into-window, in addition to doing
> "bring-region-into-sight" ensures that it's the isearch-point end of it
> which is visible when it is too big for the window. This may be
> problematic for other uses, like in ediff.
I doubt this will be problematic. It seems quite natural for
"bring-region-into-sight" to take as arguments not just the region but
also some indication of the part to favor in case it can't all
be displayed.
> Question is, what about the main bug? The patch I wrote fixes a real
> bug, and works (modulo any remaining bugs). Do you have any concrete
> suggestions as to how to improve the fix?
Hmm... I'm sorry I got lost along the way. I thought the whole patch is
the bug fix (and the bring-region-into-sight part does seem like
a bug-fix as well, tho maybe of top priority, admittedly).
Could you show which part of the patch addresses the main bug?
Stefan