bug#17453: Isearch doesn't work properly with Follow Mode.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Right, I think introducing new functions/hooks to get the
>> beginning/end of the visible part of the buffer, which can then be
>> overridden by follow-mode would probably be part of the solution.
> OK, but it really needs a window list as a parameter, and that needs to
> be stored in a variable somewhere.

I don't understand.  Why would it need to be both in a parameter and in
a variable somewhere?  And isn't it already in some follow-mode
"variable" somewhere?

window-start does not need a window parameter (it does accept such
a parameter, optionally, but that's just to avoid some
with-selected-window), so I don't think such new function would need
such a parameter either.

> I don't really see opportunities for this whose costs don't outweigh
> them.  We can make a variable called `window-start-function', but then
> everybody has to start using

>     (funcall window-start-function w)

I see two options:
- either some/many calls need to be changed to use the new API.
- or follow-mode advises window-start.

And of course, it would be (funcall window-start-function), without the `w'.

> which is a little more obfuscated and confusing than
>     (window-start w)

To make it less obfuscated, we can provide a new function
`viewable-area-start' which does (funcall window-start-function).

> .  The last form is typically going to be much faster when Follow Mode is
> active (see below).

Not sure about "much".  My gut feeling would be rather around "not
noticeably".

>> I don't see why you'd need to pass anything like a window or a list
>> of windows.  All it needs is a region and a point.  The window (or set
>> thereof) would be passed implicitly via selected-window, as usual.
> Because each time the Follow Mode window list

I don't see why.  Isn't/can't the "Follow Mode window list" be kept as
a window-parameter, so you can get it quickly?

> would have to be recalculated, and this is a moderately expensive
> calculation, involving filtering and sorting the windows in a frame
> (`follow-all-followers').  This is no big deal once per command, but
> if done much more often will start to drag.

Indeed, recomputing it for every window-start call would make it
expensive.  I assume that it can be cached such that we only recompute
it when it changes (e.g. using window-configuration-change-hook).

> There is one place where I think it is unavoidable, and that is adding
> lazy highlight overlays.  These are currently given a `window' property
> to restrict their effect to the current window.  In my patch, a
> particular match gets _two_ (or even several) overlays when it spans two
> or more Follow Mode windows.  This can surely not be abstracted away in
> any sensible way.

You might be right.  As mentioned, I think follow-mode is important
enough to warrant special treatment, so we can probably leave a few
hacks in there, in case no useful/sensible abstraction can be invented.

In this case of isearch-vs-followmode, I think the way to find the
useful abstractions is to try and figure out "what would be
useful/useable for other packages than isearch".

Window-specific overlays are not used very often, the candidates seem to be:
- region highlighting.
- rectangular region highlighting.
- compare-w.el.


        Stefan