bug#3192: 23.0.92; disabling tooltip-mode inhibits showing Customize error msgs

[Eli Zaretskii]

> From: Mauro Aranda <maurooaranda@gmail.com>
> Date: Mon, 2 Sep 2019 08:16:21 -0300
> Cc: Stefan Kangas <stefan@marxist.se>, 3192@debbugs.gnu.org
> 
> >> +     ;; Only stop displaying the message when the current message is our 
> >> own.
> >> +     ;; This has the advantage of not clearing the echo area when
> >> +     ;; running after an error message was displayed.  (Bug#3192)
> >> +     ((equal-including-properties tooltip-help-message (current-message))
> >>        (message nil)))))
> >
> > I think this will effectively disable tooltip messages in the echo
> > area in too many situations.
> 
> Sorry, I don't think I follow.  The clause I propose would replace a
> clause whose condition is `t'.  So the new code would run, at most, in the
> same cases that the current code, right?  And the two clauses (the
> current, and my proposed replace) call `message' with a nil argument, so
> if there is some disabling, it is already happening, right?

My point is that this fix is not as good as possible.  I'm asking
whether we can do better than this.  If not, can you explain why not?

> But I can't figure out why this code (or the current code) would be
> disabling tooltip messages.  AFAIU, the case when there is some message
> to show is already handled in the first of the clauses, with the
> condition: (stringp help).

If this is already handled, then why do we need this change at all?
What use case does it handle that the current code doesn't?

> > How about if we show the tooltip in these cases for only some short
> > enough period of time, like 2 sec, and then restore the original
> > contents of the echo area?
> 
> There should be no tooltip message to show, because this condition would
> be reached if HELP is nil.  (HELP might be either a string or nil, just
> like in `tooltip-show-help' function).  So I think when the two
> previous conditions were not meet, it indicates that it is time to clear
> the echo area.  But we shouldn't do that unconditionally, only when the
> current message is that of a tooltip.

Then I guess I didn't understand your analysis of the original use
case and what happens there.  Could you perhaps describe that use case
in more detail?

Thanks.