Hrvoje Niksic <hniksic(a)srce.hr> writes:
How can you know that? I need it for isearch, which is bound to one
window.
Have you tried this? When I open two windows viewing the buffer the
isearch highlighting occurs in both windows.
Maybe that is wrong.
Your needs (lazy-shot) are quite different, and harder to
meet. For me, window-start and window-end really do provide what I
want.
The reason for that is that when you are in isearch you more or less
control the event loop. However I think this a very special situation.
A situation that is also handled by lazy-shot style handling;
Wouldn't love to simply be able to say
(do-on-demand 'isearch-highlight-other-matches-in-region)
and have the rest be done for you?
Do you handle font changes, window resizing etc? You are basically
trying to reinvent lazy-lock v1 for your special case. Maybe the
problems don't hurt you that much in the special case but it still has
a "wrongish" feel to me..
> I think the non-GUARANTEE values is wrong.
This may be so. However, it's exactly the value I need,
Why do you care about lines?
You think wrong.
Try this: visit a largish file, and evaluate:
(progn
(goto-char (point-max))
(window-start))
OK, but this isn't really the same problem. You do not really want to
force a redisplay, you want to force the code that makes sure point
always stays visible to be run. You have a point in that might be a
good thing to add in a `guarantee' argument for site-start.
Jan