bug#23341: x-show-tip does not respect the value of tooltip-hide-delay, and the default tooltip timeout isn't configurable

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> Everything that's not determined by the specific
> call that `tooltip-show' makes of `x-show-tip'.

Which includes?  Almost everything `x-show-tip' accepts can be changed
when using `tooltip-show', and anything that cannot is simply unsafe,
because none of the code was designed around or tested with that
assumption.

> IOW, the only possible input to the whole deal,
> affecting the appearance, is TEXT.  All the
> rest is baked in. 

There could also be `tooltip-frame-parameters', but I fail to see the
relevance.

> Now, you can say that code could always bind
> all of those `tooltip-*' thingies around a call
> to `tooltip-show'.  Sure, it could.  It could
> end up redefining, in effect, `x-tooltip-show'.

That is indeed the way to go.

> I'd say it makes more sense to (also) let users
> use the more general, more versatile function
> itself, `x-show-tip' - just as `tooltip-show' does.

I disagree, once again, because it's simply not safe.  If someone
volunteers to look through all the X-related code that involves
accessing frame widgets, pseudo windows, redisplay, and other frame
parameters and window properties such as `override-redirect' and
WM_TRANSIENT_FOR, then that might be okay, but so far nobody has done
that.  (And probably nobody will either, since no matter what you say,
`x-show-tip' is still an internal function that user code should not
touch.)