I'm trying to figure out whether there's some bug here.
There is no other bug, AFAIK; the flash length is the only problem.
What ``other frame''? We _are_ talking about "emacs -Q", are we? In
"emacs -Q", "M-x grep" pops up a window, not a frame.
emacs -Q
(setq pop-up-frames t)
But "emacs -Q" doesn't have pop-up-frames set to t. Is the problem
related to this setting, or do you see the same sometimes-invisible
flash even with the default value of pop-up-frames? If these two are
related, perhaps setting pop-up-frames to t should modify the default
of next-error-highlight.
IMO, the flash is too short. It is too easy for users not to notice it at
all. This difficulty is even more evident when pop-up-frames = t, because
the flash location is further from the click, in terms of both distance and
time. The flash position may be behind the *grep* frame. Its frame needs to
be raised, even if the flash location is not overlapped. Its buffer needs to
be scrolled (redisplayed) to show the target location, in any case.
With pop-up-frames = nil, the behavior is only a little better. It is still
very likely that users will not notice the flash. If you use C-x ` instead
of clicking hits out of order, then it is more likely that the target
location is already visible, so in that case the flash is more likely to be
seen. If you use the mouse, and the flash location is initially off window,
then the flash is less noticeable.
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
