[Top][All Lists]

[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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]