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

[Drew Adams]

    >     FWIW, I like the current behavior and vote against changing the
    >     default.
    >
    > Would you object if it were 2 seconds?

    Yes.

    > If so, why?

    Because the overlay stays put for a prolonged time and distracts my
    attention.

So customize it to a shorter time or eliminate it altogether in your setup.
That's what customization is for.

    Also, a prolonged highlight looks like part of the buffer's
    fontification, so it's not easy to understand what it wants to say
    until it goes away.  A short blink of the highlight, by contrast, does
    a very good job of instantly showing me where the spot is, and then
    disappears, leaving me with only the normal buffer contents.

    I might agree to a longer default delay if the overlay would go away
    the moment some input event comes in; currently it doesn't.

I agree that behavior would be a good option.

A value of t makes it at least  move to the next occurrence, erasing it
where it was. To me, that's the ideal behavior, except for needing a way to
turn it off when finished using `next-error'.

    In any case, this issue sounds very minor to me, hardly something we
    should bother with now.

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.

If the default highlighting is imperceptible, then users will not know about
it to increase the period length (to actually use the highlighting
feature!). If the default highlighting is too long, at least you know it's
there, and you can customize it to be shorter.

IMO, the default should be t, but multiple seconds would be an acceptable
default also. A default value that effectively turns this off is not
acceptable, IMO.