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