emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Default value of next-error-highlight is too small


From: Drew Adams
Subject: RE: Default value of next-error-highlight is too small
Date: Sat, 16 Sep 2006 21:01:12 -0700

    >     > I've mentioned more than once that the 0.1 second period
    >     > means that the highlighting is not even noticeable on my
    >     > system (Windows XP). Invisible. Nothing. Imperceptible.
    >     > I didn't even know that this
    >     > highlighting was available to customize.
    >
    >     I don't know why; I have an XP system as well, as the
    >     highlighting is clearly perceptible.  Does that happen
    >     for you with "emacs -Q" as well?
    >
    > Yes. 0.1 seconds is very short. That is my point.

    ``Not noticeable, invisible, nothing'' is very different from ``very
    short''.  Which is it?  Is the highlight indeed invisible on your
    system, or just too short to your liking?

I said "Yes", that happens for me with emacs -Q as well. The highlighting is
not noticeable.

I also said "0.1 seconds is very short."  1/10 sec is very short for
practically anything that we expect the user to notice. This is a general
comment about UI interactions.

I said that on my system, the highlighting was "not noticeable",
"invisible", and "imperceptible". I said that I did not notice any
highlighting, and that was the reason that I was unaware of this user
option. You either believe me or you don't. I've repeated it more than
should be necessary.

My point is that other users may also not notice the highlighting, because
0.1 seconds is not long enough for them to notice it.

To be even clearer -

On my system, with emacs -Q, if you are already looking at the position that
is highlighted (!), and you continue to look at it while you click the grep
link in the *grep* buffer, it is in fact possible, sometimes, to notice a
very brief flash. You must look very carefully, and you must know where to
look. That is after knowing that this feature exists - one will never
discover the feature that way.

However, in my situation, at least, even those conditions do not apply. I
use pop-up-frames = t, so the buffers are normally in separate frames, which
may overlap to some extent.

Even with the target buffer already open, and already open to the same
target location (e.g. click the same grep line twice in a row), and even
when I am looking straight at the target position, to see if it will flash,
it is usually impossible to detect any flash at all. Perhaps that is due to
the time for Emacs to move the focus to the other frame; I don't know.

Much more importantly, I am not normally already staring at the target
location, to see if it will flash (!). The buffer might not even be
displayed until I click the grep link - in that case, the time to create the
frame is added. And even if the buffer is already displayed, it is, in the
general case, not showing the target location until I click the grep hit
line - and by the time the target location in the buffer is displayed, the
flash has occurred, with no possibility of perceiving it. And, if the *grep*
frame overlaps the target-buffer frame at all, even if the target frame is
already displayed, there is also the time needed to raise the target frame
to the front.

I hope by now I've made it clear that the flash is really imperceptible with
emacs -Q, at least on my Windows XP box (which is a pretty fast machine with
a gig of memory) when pop-up-frames = t.

I don't know why you're so obstinent, Eli. Do what you want. Go ahead and
configure the Emacs defaults to your personal preferences. I've already
customized this option for myself. If you don't care about other users who
also might not be able to perceive any highlighting, and so might also be
unaware of this option, so be it. Have a nice day. I really have nothing
more to add to this thread.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]