Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> 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.
The highlighting is there, but isearch itself always happens in one
window. If you try to change the window (or frame or buffer or
anything), isearch is done. That's how it's been for ages.
For some time I considered "correctly" handling this case by
highlighting all visible regions in all windows, but I rejected the
idea because it would be too much work for practically no gain. When
the isearch is in progress, we tend to look at the window where it
happens. When the isearch ends, so does the highlighting.
> > 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
It is; that's why window-end suits me and that's why I reported a bug.
> 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?
Yes, it would be nice, but it's hard to do right. Ideally, you'd want
the code to be called after the redisplay has calculated what needs to
be done, but before it is actually done. But your code could change
the screen layout and thus invalidate the previous calculation. This
would require a recalculation, leading to your code being reinvoked,
etc. It's very easy to infloop there.
You can either do what I do and change things on your own risk, or do
what lazy shot does, and enjoy the flicker. For isearch, the two
approaches amount to (almost) the same thing, and I believe mine is
Oh, and note that even in the case of isearch the `do-on-demand' code
might prove deficient. For the highlighting to be meaningful in all
cases, it requires an anchoring point, normally provided by the
location of point in isearch. If you just try to find matches
beginning with a random point, your code will suffer from the "banana
phenomenon"; see my article on comp.editors for details.
But none of it is really relevant. Philosophical discussions are
nice, but I only really wanted to draw attention to a bug in
> > > 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?
I do not understand the question.
> > 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.
Huh? It is quite obvious that lack of redisplay causes window-start
to return the wrong value. If my understanding is correct, the
GUARANTEE argument was invented *exactly* for that purpose -- to get
the correct value without forcing a redisplay.
Bugs notwithstanding, it is very strange that window-end is provided a
GUARANTEE argument, while window-start is not.
> 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.
That code is buried deep in redisplay. I don't think you can just
"force it to be run" without also triggering redisplay. Or, do you
mean that the redisplay code should be run, while the redisplay
*output* should be suppressed?