bug#5122: Mismatched parentheses when dealing with hugebuffercontent

["Drew Adams" <drew.adams@oracle.com>]

> >> Error messages shouldn't be so verbose---they can't spell 
> >> out every bell and whistle related to the error.
> >
> > I'd say adding a couple of words is hardly verbose, and certainly
> > isn't spelling out every detail.
> >
> >> I prefer leaving things the way they are.
> >
> > And leave users without a clue? how's that preferable?

Eli is right.

It is plain poor judgment to leave things the way they are in this case.
 
> The circumstances in which the parenthesis are mismatched probably
> vastly outweigh the circumstances in which the user wants to change
> blink-matching-paren-distance.

That's one point, sure. But the opposing consideration is how much damage occurs
when the problem, rare though it might be, does arise.

When a false mismatch occurs, the user has no clue - truly no clue - as to what
is going on. (This is in fact truer the rarer the event is!)

I know this because it happened to me. That's why I was able to respond to
Deniz's bug report so quickly. I just went through the same thing a month or so
back.

(And yes, I had already known this years ago, but had forgotten - perhaps
because of the rarity. I was looking at code from someone else (BBDB), which
uses much larger function definitions than I do.)

I spent quite a bit of time trying, in vain, to figure out what the problem was
with the code (e.g. an unescaped left paren in col 1 of a doc string, escape
sequences in regexp strings,...).

And that's the point, the opposing consideration: the difficulty and
improbability of finding the explanation/solution. One's reflex is not to
suppose that this is normal behavior governed by some user option. Believe me.
The tendency is to try to find out what is causing the mismatch. No one
spontaneously doubts that there is a mismatch.

This is very different from some other limits we have in Emacs. When a buffer is
bigger than the default font-locking buffer size, you can tell: there simply is
no font-locking. So if you're ignorant of the cause/remedy in that case, you
naturally search for something having to do with font-locking - you can tell
that there is a font-locking problem. You search a bit, and you eventually find
`font-lock-fontify-buffer' and solve the problem.

But here the natural inclination is to assume, since there is mismatch
highlighting, that there is, well, a mismatch. Duh.

I said the user has no clue as to what's going on in this situation. But it's
actually worse than that. We lead the user down the garden path. We say, in
effect, "Look over there! (without saying where)".

Gotcha! Look all you want over there, but there is nothing to find. The problem
is right here. It lies with the messenger who's telling you to look over there.

The paren-mismatch-highlighting code itself _knows_ when it has reached its
limit (or it should know), so it _knows_ when its highlighting no longer makes
any sense and can only mislead. It is up to that code to DTRT and - at a minimum
- do nothing in this context; do no harm. Better would be for it to signal
explicitly that it has gone beyond its limit.

> So, it is arguably more confusing to the average user if the error
> message mumbles something about blink-matching-paren-distance.  For
> those who care, it's an apropos search away.

You seem to have an interesting understanding of what is confusing to users,
average or otherwise.

And I couldn't disagree more about the ease of finding the problem, "for those
who care". To find it, you need to be looking for it. You need to have some idea
of what is going on, some idea that the paren highlighting is not functioning
normally and its helpful indicator should not be trusted. You need some hint
that you should look for an option concerning parens.

When you see mismatch highlighting, you do not assume that something is wrong
with the highlighting (or that some limit has been surpassed for its normal
functioning). You assume instead that there is in fact a mismatch somewhere.
_You trust what Emacs tells you._

Imagine if compiler error messages showed up spuriously, incorrectly, whenever
some esoteric threshold was surpassed - a setting that you didn't even know
about. Would you even think to look for such a setting? Or would you instead,
naturally, believe the compiler error message and dive into a close examination
of your code to try to understand its problem. Yes, you would look over there...

Emacs is misleading users in this situation. It is staring up at the top of a
building, causing others to look up also, even though there is nothing to see
there.

If you are really worried about the intrusiveness of an explanation in the echo
message or in a tooltip (remember, the mouse would need to be over the
"mismatched" paren for the tooltip message to appear, and the message would only
need to be displayed when the threshold is in fact surpassed), then consider
simply _not highlighting_ at all whenever the search distance has been exceeded.

Turning off highlighting in this case would at least clue the user to look for
something having to do with paren highlighting. What is bad design ("confusing
to the average user") is blindly signaling an error (mismatch) when the
measuring tool knows (or should know) that it is currently incapable of
measuring at all!

[Also, this option/feature should not necessarily be called "blink" anything, or
at least an alias should be provided, so that it would be easier to find for
those who use `show-paren-mode'. If one uses paren highlighting, then this is
more obviously about paren highlighting than paren blinking.]