[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 17:46:53 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
>> 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