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

[Drew Adams]

> > 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',

Huh?  _None_ of `x-show-tip's args is available
to `tooltip-show' - except the TEXT/STRING arg.

> and anything that cannot is simply unsafe,
> because none of the code was designed around 
> or tested with that assumption.

Anything safe enough for `tooltip-show' to use
is safe enough for `x-show-tip' to use.  That
much should be obvious, and that much you
should agree with, I think.

All the former does is call the latter.  The
args it passes to `x-show-tip' are wide open
as to their possible values.

Limiting args passed to `x-show-tip' to the
possible values that `tooltip-show' can pass
to it clearly doesn't change anything wrt
"danger" or something that's not designed
or is untested.

It's only a question of HOW those values are
passed - in a crude, clumsy, straitjacket
way or in the usual, open, Lispy arg-passing
way.

Now maybe you want to make an explicit claim
that the set of all possible values for those
`tooltip-*' settings are all that should ever
be passed to `x-show-tip', because they're
all you're sure of (designed, tested).

If so, go right ahead.  Put that in the
guidance, if you're so sure of those values,
and so unsure of any others.

> > 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.

That, and every other arg that `tooltip-show'
passes to `x-show-tip' - face `tooltip',
`tooltip-*' vars, etc.  Pretty wide open.

Collect all their possible values, if you think
they're so well designed and tested.  Tell users
of `x-show-tip' to use only those values as args.
End of story.

Then you end up, in effect, with a better, more
flexible, more normal, more lispy `tooltip-show'.

You end up with `x-show-tip' plus your guidance,
which you seem to be so sure of (though it's
pretty smoky, so far).  Go for it, if that's
your real message: only those values are sure
and safe.

Only whatever face `tooltip' could possibly be.
Only what `tooltip-frame-parameters' could be.
Only what `tooltip-hide-delay', `tooltip-x-offset',
and `tooltip-y-offset' could possibly be.

Do you really believe that their possible values
make things safe?  Fine, tell users not to use
any other values.  I don't have a problem with
your telling users that - not at all.  That's
still _wide open_.

> > 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.

Really?  You really think so?

> > 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.

See above.  Same safety - identical.

(defun foo (string &optional frame parms timeout dx dy
                             use-echo-area)
  (with-selected-frame frame)
    (let ((text                      string)
          (tooltip-frame-parameters  (copy-sequence parms))
          (tooltip-hide-delay        timeout)
          (tooltip-x-offset          dx)
          (tooltip-y-offset          dy))
      (tooltip-show text use-echo-area))))

Does that make you feel safer?
        
> 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.)

Bof.  More bluster.