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

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 218 bytes --]

It would be nice to have a lisp-configurable default for tooltip timeout; currently, it is hardcoded to 5 seconds in x_show_tip.

There already exists a variable that could serve this purpose: tooltip-hide-delay.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Fri, 22 Apr 2016 22:47:28 -0400
> 
> It would be nice to have a lisp-configurable default for tooltip timeout; currently, it is hardcoded to 5 seconds in x_show_tip.

??? That hardcoded value is only used if the optional argument TIMEOUT
is nil, so I'm not sure I understand what you are saying.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

On 2016-04-23 02:53, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Fri, 22 Apr 2016 22:47:28 -0400
>>
>> It would be nice to have a lisp-configurable default for tooltip timeout; currently, it is hardcoded to 5 seconds in x_show_tip.
> 
> ??? That hardcoded value is only used if the optional argument TIMEOUT
> is nil, so I'm not sure I understand what you are saying.

I'm saying that it would be nice for users to be able to set a global default that applies in all cases in which a package uses x-show-tip and doesn't pass the appropriate argument (or make it user-configurable) :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> Cc: 23341@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 23 Apr 2016 10:22:09 -0400
> 
> >> It would be nice to have a lisp-configurable default for tooltip timeout; currently, it is hardcoded to 5 seconds in x_show_tip.
> > 
> > ??? That hardcoded value is only used if the optional argument TIMEOUT
> > is nil, so I'm not sure I understand what you are saying.
> 
> I'm saying that it would be nice for users to be able to set a global default that applies in all cases in which a package uses x-show-tip and doesn't pass the appropriate argument (or make it user-configurable) :)

Which package(s) do that?  I think those packages need to be fixed
instead.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1080 bytes --]



On 2016-04-23 10:36, Eli Zaretskii wrote:
>> Cc: 23341@debbugs.gnu.org From: Clément Pit--Claudel
>> <clement.pitclaudel@live.com> Date: Sat, 23 Apr 2016 10:22:09
>> -0400
>> 
>>>> It would be nice to have a lisp-configurable default for
>>>> tooltip timeout; currently, it is hardcoded to 5 seconds in
>>>> x_show_tip.
>>> 
>>> ??? That hardcoded value is only used if the optional argument
>>> TIMEOUT is nil, so I'm not sure I understand what you are
>>> saying.
>> 
>> I'm saying that it would be nice for users to be able to set a
>> global default that applies in all cases in which a package uses
>> x-show-tip and doesn't pass the appropriate argument (or make it
>> user-configurable) :)
> 
> Which package(s) do that?  I think those packages need to be fixed 
> instead.

I don't have a comprehensive list; I could compile one, but regardless of that: I don't want to have to configure every package that I use independently. It's good to be able to fine-tune independent packages, but consistent defaults are nice in any case, aren't they?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> Cc: 23341@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 23 Apr 2016 11:26:57 -0400
> 
> > Which package(s) do that?  I think those packages need to be fixed 
> > instead.
> 
> I don't have a comprehensive list; I could compile one, but regardless of that: I don't want to have to configure every package that I use independently. It's good to be able to fine-tune independent packages, but consistent defaults are nice in any case, aren't they?

I don't think it's right for Emacs to provide such ugly global hacks
because some packages out there don't give users ways to customize the
tooltips.  The hard-coded value we provide is the last resort,
nothing more, nothing less.

Bottom line, I think the bug is in the packages that don't provide
customizations for this, and you should take this up with the
respective maintainers.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 926 bytes --]

On 2016-04-23 13:54, Eli Zaretskii wrote:
> I don't think it's right for Emacs to provide such ugly global hacks
> because some packages out there don't give users ways to customize the
> tooltips.  The hard-coded value we provide is the last resort,
> nothing more, nothing less.
> 
> Bottom line, I think the bug is in the packages that don't provide
> customizations for this, and you should take this up with the
> respective maintainers.

Eli, thanks for your responses. I'm sorry that I didn't make the original bug report clear enough.

As a user, I would like to have a way to globally configure how long tooltips produced by Emacs are displayed.
At the moment, Emacs does not provide such a default. tooltip-hide-delay is close, but it does not cover all tooltips.

As a user, I don't like it to have to customize every package that use tooltips to just to ensure a consistent default.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> Cc: 23341@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sat, 23 Apr 2016 18:33:13 -0400
> 
> As a user, I would like to have a way to globally configure how long tooltips produced by Emacs are displayed.
> At the moment, Emacs does not provide such a default. tooltip-hide-delay is close, but it does not cover all tooltips.
> 
> As a user, I don't like it to have to customize every package that use tooltips to just to ensure a consistent default.

I understand, thanks.  But to me, such a global value makes very
little sense, because tooltips can be used for many different features
that don't necessary display short helpful text.  Having a single
value for all the possible use cases is IMO not a good customization
design, as it can never be a "one fits all" value anyway.

Once again, the current hard-coded value is not a global default, it's
the last resort that is clearly not meant to be used except in very
rare situations.  Developers of features that use tooltips via direct
calls to x-show-tip are encouraged to invest some serious thought into
how they want this aspect be customizable by their users, and provide
defcustom's as appropriate.  Alternatively, they could use
tooltip-show, as the documentation suggests, in which case the
defcustom's already present in tooltip.el will do.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]

On 2016-04-24 02:08, Eli Zaretskii wrote:
>> Cc: 23341@debbugs.gnu.org
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sat, 23 Apr 2016 18:33:13 -0400
>>
>> As a user, I would like to have a way to globally configure how long tooltips produced by Emacs are displayed.
>> At the moment, Emacs does not provide such a default. tooltip-hide-delay is close, but it does not cover all tooltips.
>>
>> As a user, I don't like it to have to customize every package that use tooltips to just to ensure a consistent default.
> 
> I understand, thanks.  But to me, such a global value makes very
> little sense, because tooltips can be used for many different features
> that don't necessary display short helpful text.  Having a single
> value for all the possible use cases is IMO not a good customization
> design, as it can never be a "one fits all" value anyway.

In that case, I don't understand why we have tooltip-hide-delay as a customizable variable, nor why the hide delay is an optional argument to x-show-tip.

But in any case, I don't think wasting Martin's or your time further is warranted; I don't want to distract the two of you from other more valuable implementation tasks, so I'll abandon this suggestion.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> Cc: 23341@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 24 Apr 2016 10:43:18 -0400
> 
> > I understand, thanks.  But to me, such a global value makes very
> > little sense, because tooltips can be used for many different features
> > that don't necessary display short helpful text.  Having a single
> > value for all the possible use cases is IMO not a good customization
> > design, as it can never be a "one fits all" value anyway.
> 
> In that case, I don't understand why we have tooltip-hide-delay as a customizable variable

We have it to provide customization for tooltip.el functions.

> nor why the hide delay is an optional argument to x-show-tip.

Because x-show-tip has a fallback, whose value is reasonable in many
situations.

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

[martin rudalics]

 > It would be nice to have a lisp-configurable default for tooltip
 > timeout; currently, it is hardcoded to 5 seconds in x_show_tip.
 >
 > There already exists a variable that could serve this purpose:
 > tooltip-hide-delay.

A function that calls ‘tooltip-show’ doesn't have to care because the
latter already uses ‘tooltip-hide-delay’ as TIMEOUT argument for
‘x-show-tip’.

A function that calls ‘x-show-tip’ directly should generally use
‘tooltip-hide-delay’ as TIMEOUT argument.  If it doesn't, it should
provide a customizable variable to use as TIMEOUT argument instead.

martin

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1600 bytes --]

On 2016-04-23 04:13, martin rudalics wrote:
>> It would be nice to have a lisp-configurable default for tooltip
>> timeout; currently, it is hardcoded to 5 seconds in x_show_tip.
>>
>> There already exists a variable that could serve this purpose:
>> tooltip-hide-delay.
> 
> A function that calls ‘tooltip-show’ doesn't have to care because the
> latter already uses ‘tooltip-hide-delay’ as TIMEOUT argument for
> ‘x-show-tip’.

That's true :)

> A function that calls ‘x-show-tip’ directly should generally use
> ‘tooltip-hide-delay’ as TIMEOUT argument.  If it doesn't, it should
> provide a customizable variable to use as TIMEOUT argument instead.

Maybe, but this isn't a documented convention AFAICS, and it's inconvenient to have to dig to find which default to set.
There's tooltip, pos-tip, 10 packages that depend on pos-tip, and probably a bunch more depending on tooltip. It would be nice to have one setting that applies in all cases where other customization has not happened, instead of using a hardcoded default. Don't you think?

I opened this issue based on the experience that it took me some non-trivial amount of time to figure out that I had to configure flycheck-pos-tip-delay, and not tooltip-delay. flycheck-pos-tip follows the convention that you outlined above, but that convention wasn't obvious to me, and doesn't yield a consistent or very nice experience (any time I install a package that uses tooltips, I need to wonder configure its timeout, unless it uses tooltip — which I can't easily guess).

Cheers,
Clément.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[martin rudalics]

 >> A function that calls ‘x-show-tip’ directly should generally use
 >> ‘tooltip-hide-delay’ as TIMEOUT argument.  If it doesn't, it should
 >> provide a customizable variable to use as TIMEOUT argument instead.
 >
 > Maybe, but this isn't a documented convention AFAICS,

We can hardly say in the doc-string of ‘x-show-tip’ that

   This is an internal function; Lisp code should call `tooltip-show'.

and then explain how to call this function from Lisp code.

 > and it's
 > inconvenient to have to dig to find which default to set.  There's
 > tooltip, pos-tip, 10 packages that depend on pos-tip, and probably a
 > bunch more depending on tooltip. It would be nice to have one setting
 > that applies in all cases where other customization has not happened,
 > instead of using a hardcoded default. Don't you think?
 >
 > I opened this issue based on the experience that it took me some
 > non-trivial amount of time to figure out that I had to configure
 > flycheck-pos-tip-delay, and not tooltip-delay.

I don't know flycheck but ‘tooltip-delay’ is the delay _before_ showing
the tip.  Earlier we were talking about ‘tooltip-hide-delay’.

 > flycheck-pos-tip
 > follows the convention that you outlined above, but that convention
 > wasn't obvious to me, and doesn't yield a consistent or very nice
 > experience (any time I install a package that uses tooltips, I need to
 > wonder configure its timeout, unless it uses tooltip — which I can't
 > easily guess).

Any package that optionally provides its own delay for hiding tips
should, by default, use the value of ‘tooltip-hide-delay’ for that
option.

martin

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1362 bytes --]

On 2016-04-23 13:08, martin rudalics wrote:
>> I opened this issue based on the experience that it took me some
>> non-trivial amount of time to figure out that I had to configure
>> flycheck-pos-tip-delay, and not tooltip-delay.
> 
> I don't know flycheck but ‘tooltip-delay’ is the delay _before_ showing
> the tip.  Earlier we were talking about ‘tooltip-hide-delay’.

Indeed, sorry; I meant flycheck-pos-tip-hide-delay.

> Any package that optionally provides its own delay for hiding tips
> should, by default, use the value of ‘tooltip-hide-delay’ for that
> option.

Isn't that one more burden that we impose on package developers for essentially no good reason? Also. what do you mean by "use the value by default"? Do you mean to initialize a defcustom? That won't work: changing the value of tooltip-hied-delay would not update that of the corresponding defcustom. Or do you mean that all packages using tooltips should explicitly pass a hide-delay argument to pos-tip or tooltip or x-show-tip, with that argument being (or package-local-delay tooltip-hide-delay)? That sounds cumbersome and error prone: if that's how we want things done, why is the delay argument optional?

In any case, do we gain anything from hardcoding 5 as the default?

Thanks for your opinion and responses! (and thanks Eli, too :)
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[martin rudalics]

 > Isn't that one more burden that we impose on package developers for
 > essentially no good reason? Also. what do you mean by "use the value
 > by default"? Do you mean to initialize a defcustom? That won't work:
 > changing the value of tooltip-hied-delay would not update that of the
 > corresponding defcustom. Or do you mean that all packages using
 > tooltips should explicitly pass a hide-delay argument to pos-tip or
 > tooltip or x-show-tip, with that argument being (or
 > package-local-delay tooltip-hide-delay)? That sounds cumbersome and
 > error prone: if that's how we want things done, why is the delay
 > argument optional?

Package ‘foo’ would evaluate the value of ‘foo-tooltip-hide-delay’
which, by default, should yield the value ‘tooltip-hide-delay’ evaluates
to unless the user has customized ‘foo-tooltip-hide-delay’.  That value
should be passed by ‘foo’ to ‘x-show-tip’.  If you can think of a better
solution with less surprising results for the user please tell me.

 > In any case, do we gain anything from hardcoding 5 as the default?

As Eli expained elsewhere this is an internal value which, ideally, is
never used.  And I fully share everything Eli said on this subject.

martin

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]

On 2016-04-24 04:40, martin rudalics wrote:
> If you can think of a better solution with less surprising results
> for the user please tell me.

Isn't using the value of tooltip-hide-delay (or of a new similar variable) as the default in x-show-tip such a solution?
In other words, what downside does it have? Sorry if I missed one. All that I've seen for now is mentions that this was an internal detail.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Sun, 24 Apr 2016 10:40:58 -0400
> 
> On 2016-04-24 04:40, martin rudalics wrote:
> > If you can think of a better solution with less surprising results
> > for the user please tell me.
> 
> Isn't using the value of tooltip-hide-delay (or of a new similar variable) as the default in x-show-tip such a solution?
> In other words, what downside does it have? Sorry if I missed one. All that I've seen for now is mentions that this was an internal detail.

The downside is that tooltip-hide-delay has no relation whatsoever to
x-show-tip.  It is a user option supported by functions in tooltip.el,
as its name says.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 797 bytes --]

On 2016-04-24 11:57, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
>> Date: Sun, 24 Apr 2016 10:40:58 -0400
>>
>> On 2016-04-24 04:40, martin rudalics wrote:
>>> If you can think of a better solution with less surprising results
>>> for the user please tell me.
>>
>> Isn't using the value of tooltip-hide-delay (or of a new similar variable) as the default in x-show-tip such a solution?
>> In other words, what downside does it have? Sorry if I missed one. All that I've seen for now is mentions that this was an internal detail.
> 
> The downside is that tooltip-hide-delay has no relation whatsoever to
> x-show-tip.  It is a user option supported by functions in tooltip.el,
> as its name says.

Hence "(or of a new similar variable)" :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[martin rudalics]

 > Hence "(or of a new similar variable)" :)

I suppose that most clients of ‘x-show-tip’ peruse this function for
showing a frame that displays more persistent information - hence the
need for customizing this delay independently from ‘tooltip-hide-delay’.

I'm currently trying to implement something like tip-like frames which
should allow applications to display an arbitrary number of such frames
and a strategy for hiding and moving such frames (the latter being the
more problematic part).  I hope that as soon as these frames can be
used, the need for a "new similar variable" will be moot ;-)

martin

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

[Dmitry Gutov]

On 04/26/2016 09:35 AM, martin rudalics wrote:

> I'm currently trying to implement something like tip-like frames which
> should allow applications to display an arbitrary number of such frames
> and a strategy for hiding and moving such frames (the latter being the
> more problematic part).  I hope that as soon as these frames can be
> used, the need for a "new similar variable" will be moot ;-)

That sounds exciting!

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

[Lars Ingebrigtsen]

Clément Pit--Claudel <clement.pitclaudel@live.com> writes:

> It would be nice to have a lisp-configurable default for tooltip
> timeout; currently, it is hardcoded to 5 seconds in x_show_tip.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Reading this thread, there were some good arguments for why we shouldn't
add such a variable -- x-show-tip isn't supposed to be called directly,
and tooltip.el already has a way to tweak this.

But x-show-tip is called directly by various things (even things
in-tree), so I think it makes sense to add such a variable, and I've now
done so in Emacs 29.  (But not as a user option -- just a variable
mentioned in the `x-show-tip' doc string.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 30 Apr 2022 17:10:59 +0200
> Cc: 23341@debbugs.gnu.org
> 
> But x-show-tip is called directly by various things (even things
> in-tree), so I think it makes sense to add such a variable, and I've now
> done so in Emacs 29.

It looks like you did that only for X?  What about the other 4
implementations of this function? is the divergence in behavior
intended?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It looks like you did that only for X?  What about the other 4
> implementations of this function? is the divergence in behavior
> intended?

Nope -- fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: clement.pitclaudel@live.com,  23341@debbugs.gnu.org
> Date: Sat, 30 Apr 2022 17:38:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It looks like you did that only for X?  What about the other 4
> > implementations of this function? is the divergence in behavior
> > intended?
> 
> Nope -- fixed now.

Err... it doesn't compile here:

    CC       w32fns.o
  w32fns.c: In function 'Fx_show_tip':
  w32fns.c:7369:15: error: 'Vx_show_tooltip_timeout' undeclared (first use in this function)
   7369 |     timeout = Vx_show_tooltip_timeout;
	|               ^~~~~~~~~~~~~~~~~~~~~~~
  w32fns.c:7369:15: note: each undeclared identifier is reported only once for each function it appears in
  Makefile:421: recipe for target `w32fns.o' failed

I think the variable should be moved to a common file, perhaps
dispnew.c?

Also, nsterm.m should be modified as well, no?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the variable should be moved to a common file, perhaps
> dispnew.c?

Oops; yup.  Now done.

> Also, nsterm.m should be modified as well, no?

Geez.  Yup; now pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: clement.pitclaudel@live.com,  23341@debbugs.gnu.org
> Date: Sat, 30 Apr 2022 18:22:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think the variable should be moved to a common file, perhaps
> > dispnew.c?
> 
> Oops; yup.  Now done.
> 
> > Also, nsterm.m should be modified as well, no?
> 
> Geez.  Yup; now pushed.

Thanks!

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Also, nsterm.m should be modified as well, no?
>
> Geez.  Yup; now pushed.

There's also haikufns.c and pgtkfns.c, which I will take care of, but I
strongly disagree that `x-show-tip' should allow its default timeout to
be configurable: people will be confused at the difference between
`tooltip-hide-delay' and that new variable, and `x-show-tip' is a
programmatic interface, _NOT_ something that should decide a delay by
itself.

So I would rather this new variable be removed, and all the places that
we call `x-show-tip' manually be fixed to respect `tooltip-hide-delay',
if appropriate.

Thanks.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>>> Also, nsterm.m should be modified as well, no?
>>
>> Geez.  Yup; now pushed.
>
> There's also haikufns.c and pgtkfns.c, which I will take care of,

I did those already, I think?

> but I strongly disagree that `x-show-tip' should allow its default
> timeout to be configurable: people will be confused at the difference
> between `tooltip-hide-delay' and that new variable, and `x-show-tip'
> is a programmatic interface, _NOT_ something that should decide a
> delay by itself.
>
> So I would rather this new variable be removed, and all the places that
> we call `x-show-tip' manually be fixed to respect `tooltip-hide-delay',
> if appropriate.

See the bug report for the discussion about this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I did those already, I think?

Yes, sorry, I missed that.

> See the bug report for the discussion about this.

I looked in the bug report thread, and ISTM that the consensus was to
not add such a variable, instead fixing all the code that used
`x-show-tip' directly to use `tooltip-show'.

In general, using `x-show-tip' directly comes with many pitfalls, some
of which are not easy to come by, so authors of third-party Lisp should
not call that function directly without a detailed understanding of the
different layers of tooltip machinery.  That understanding includes
providing an appropriate `timeout' parameter.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> In general, using `x-show-tip' directly comes with many pitfalls, some
> of which are not easy to come by, so authors of third-party Lisp should
> not call that function directly without a detailed understanding of the
> different layers of tooltip machinery.  That understanding includes
> providing an appropriate `timeout' parameter.

As I said in the bug thread, I agree with that, but nevertheless,
x-show-tip is still used directly -- even in-tree -- so adding a
(non-user option) variable to allow tweaking is appropriate.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I said in the bug thread, I agree with that, but nevertheless,
> x-show-tip is still used directly -- even in-tree -- so adding a
> (non-user option) variable to allow tweaking is appropriate.

If code calls `x-show-tip' directly, then that means it explictly wants
a 5 second delay: no more, no less.

If that is not actually what it wants, it should be fixed, instead of
hacking around the problem with a global variable.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> If code calls `x-show-tip' directly, then that means it explictly wants
> a 5 second delay: no more, no less.

The user should be able to override what they want.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> If code calls `x-show-tip' directly, then that means it explictly
>> wants a 5 second delay: no more, no less.

> The user should be able to override what they want.

So why don't we have variables enabling the user to customize the
"default" value of each optional parameter to every internal function,
such as the default values of `default-filename', `mustmatch' and
`only-dir-p' in Fx_file_dialog?  Or the default `action' in
`x-begin-drag'?

This specific case is even worse, since we now have two different
variables for customizing two subtly different kinds of "tooltip hide
delay".

That way lies madness.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> So why don't we have variables enabling the user to customize the
> "default" value of each optional parameter to every internal function,
> such as the default values of `default-filename', `mustmatch' and
> `only-dir-p' in Fx_file_dialog?  Or the default `action' in
> `x-begin-drag'?

Allowing the user to alter those doesn't seem useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Allowing the user to alter those doesn't seem useful.

But there are external packages calling that function utilizing the
default meanings of its parameters, and it's also an internal function
used by `read-file-dialog', so the analogy with `x-show-tip' is
complete.

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

[Drew Adams]

> But there are external packages calling that function utilizing the
> default meanings of its parameters, and it's also an internal function
> used by `read-file-dialog', so the analogy with `x-show-tip' is
> complete.

FWIW, I don't see why `x-show-tip' is being
considered "internal".  And I'm one who uses it in
external libraries.

If `tooltip-show' can use `x-show-tip' then so
can "external" code that does something similar.

The only even partially good excuse for branding
something "internal" is to let users know not to
depend too heavily on its behavior, as it might
change sometime.  (And that's anyway true of
everything in Emacs.)

`tooltip-show' is not sufficiently general to
serve as a replacement for the use cases of
`x-show-tip'.  Branding the latter "off limits"
is misguided, IMO.

This, in the `x-show-tip' doc string, is misguided:

  This is an internal function; Lisp code should
  call `tooltip-show'.

(No reason given, BTW.  Nothing that helps users
understand.  Just a big "VERBOTEN !" sign.)
___

On the other hand, there's nothing wrong with
_documenting_, clearly, any caveats that you
think users of `x-show-tip' should be aware of.

And by "documenting" I don't mean hand-waving
about unspoken, unclear "complications".
___

Even the title of this bug should be a clue
that something is wrong about it: the tail is
wagging the dog.  Why should `x-show-tip'
respect the value of `tooltip-hide-delay'?

It's the other way around: `x-show-tip' does
not, and should not, depend on any `tooltip-*'.
It's `tooltip-*' that depends on its use of
`x-show-tip'.
___

What Martin said in this bug thread is sound:

  A function that calls 'x-show-tip' directly
  should generally use 'tooltip-hide-delay' as
         ^^^^^^^^^
  TIMEOUT argument.  If it doesn't, it should
  provide a customizable variable to use as
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  TIMEOUT argument instead.

That's reasonable.  If you can reasonably use
`tooltip-show' then do so.  If you can't, use
`x-show-tip'.

And in the latter case, if it makes sense to
use `tooltip-hide-delay' as the TIMEOUT arg,
then do so.

If not, then if you can reasonably provide a
user option, to let users specify the TIMEOUT
to use, then do so.

Different uses of showing a tooltip can call
for different behaviors, including different
TIMEOUT values.  For some uses the general
option `tooltip-hide-delay' is appropriate.
For others it's not - instead, you want to
let users specify another timeout value.

Martin also suggested:

  Any package that optionally provides its
  own delay for hiding tips should, by default,
  use the value of 'tooltip-hide-delay' for
  that option.

That too makes sense, _in general_.  But
"should" should be avoided in such guidance,
unless "in general" follows.  The devil is
in the details, i.e., in what the use case is.

None of this is complicated.  None of it is
a reason to call `x-show-tip' off limits.
___

And what Martin said about `x-show-tip' arg
TIMEOUT is also sound for args DX and DY:
use options `tooltip-[xy]-offset', or
provide library-specific options.
___

The bug filer even admitted the following,
in response to Martin's clear advice:

  this isn't a documented convention AFAICS,

That calls out for the _proper_ "fix": Just
add what Martin suggested to the doc.  Don't
make a mountain out of this mole hill.
___

This, I think, is the bottom-line expression
of the bug OP's problem:

  I opened this issue based on the experience
  that it took me some non-trivial amount of
  time to figure out that I had to configure
  flycheck-pos-tip-delay, and not tooltip-delay.

  flycheck-pos-tip follows the convention that
  you outlined above, but that convention wasn't
  obvious to me, and doesn't yield a consistent
  or very nice experience (any time I install a
  package that uses tooltips, I need to wonder
  configure its timeout, unless it uses tooltip
  - which I can't easily guess).

IMO, this just points to a case of either or
both (1) something (`flycheck-pos-tip') not
being well-enough documented or (2) a user not
using `C-m' or otherwise checking what a library
provides before using it.

If Flycheck provides an option for the hide
delay it uses, and if it makes that provision
obvious, then I don't see a Flycheck bug (or
any other bug).

Eli said something similar, I think:

  Bottom line, I think the bug is in the
  packages that don't provide customizations
  for this, and you should take this up with
  the respective maintainers.

(I say "I think", because maybe he meant more
than that, about an option.  Maybe he too
meant to suggest that no library should use
`x-show-tip'.)

If in fact it makes better sense for Flycheck
to _not_ provide its own delay option, and
instead to just use `tooltip-hide-delay', then
change it to do that.  (I have no opinion here.)

But there's no requirement that code that uses
`x-show-tip' use anything `tooltip-*'.  That
would be backward: the tail wagging the dog.

3rd-party code, just as much as `tooltip.el',
can reasonably make use of `x-show-tip'.

The OP's complaint is essentially this:

  I don't want to have to configure every
  package that I use independently.  It's
  good to be able to fine-tune independent
  packages, but consistent defaults are nice
  in any case, aren't they?

And this:

  As a user, I would like to have a way to
  globally configure how long tooltips
  produced by Emacs are displayed.  At the
  moment, Emacs does not provide such a
  default. tooltip-hide-delay is close, but
  it does not cover all tooltips.

It can't - and it shouldn't necessarily -
cover all tooltips, because Emacs cannot
know how some particular library (use case)
might make use of tooltips.  OP's
inconvenience is the cost of not being able
to predict and reasonably cover every use
case.

So the answer is yes, consistency is nice
when it makes sense.  But yes, if it makes
sense for a library to provide its own
settings, such a options, as opposed to just
using a generally/globally "consistent"
setting, then it's up to you as a user to
recognize that fact and act accordingly.

If a library gives you an option to get the
behavior you like as a user, then don't
complain that it's a bother to specify that.
If _you_ think that option should default
to the value of a more general option, then
tell it to the library maintainer.  It's
possible that the maintainer has a good
reason to have provided you with a separate
option.

Or not.  IOW, it's either a problem with
that library or a user problem.  It's not a
problem with `x-show-tip'.  One person's
inconvenience for having to customize more
than just one option is another person's
relief in being able to get behavior, in a
particular context, that differs from what
that general option provides.

As Eli put it:

  to me, such a global value makes very
  little sense, because tooltips can be
  used for many different features that
  don't necessary display short helpful
  text.  Having a single value for all the
  possible use cases is IMO not a good
  customization design, as it can never be
  a "one fits all" value anyway.

And he says this, with which I also agree:

  tooltip-hide-delay has no relation
  whatsoever to x-show-tip.  It is a user
  option supported by functions in tooltip.el,
  as its name says.

No relation, although I also agree with
Martin's suggestion that it can make sense
to use that option in a call to `x-show-tip'
when other things are equal (i.e., when
there's no good reason not to).
___

There were good things said in this thread.
This is not one of them, IMO:

  Reading this thread, there were some good
  arguments for why we shouldn't add such a
  variable -- x-show-tip isn't supposed to
  be called directly, and tooltip.el already
  has a way to tweak this.

Drop the "x-show-tip isn't supposed to be
called directly".  That's misguided.  The
rest is fine.
___

Just one opinion, from one 3rd-party provider,
who sometimes uses `x-show-tip' with
`tooltip-hide-delay' and sometimes uses it
with a delay option designed for use with a
specific library that calls `x-show-tip'. 

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> FWIW, I don't see why `x-show-tip' is being
> considered "internal".  And I'm one who uses it in
> external libraries.
>
> If `tooltip-show' can use `x-show-tip' then so
> can "external" code that does something similar.

`x-show-tip' is an internal function because it exposes dangerous
features to Lisp.

If the `frame' parameter is an invisible frame, the tooltip will be
displayed unpredictably by different window managers.

There are also some things you can put in `params' that will make Emacs
crash, but I don't remember which.

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

[Drew Adams]

> > FWIW, I don't see why `x-show-tip' is being
> > considered "internal".  And I'm one who uses it in
> > external libraries.
> >
> > If `tooltip-show' can use `x-show-tip' then so
> > can "external" code that does something similar.
> 
> `x-show-tip' is an internal function because it exposes dangerous
> features to Lisp.

Dangerous?  Too dangerous for Lisp?  Please
do elaborate.

> If the `frame' parameter is an invisible frame, the tooltip will be
> displayed unpredictably by different window managers.

Lots of things can happen unpredictably with
frames, per different window managers.

And invisible frames are used seldom - so
much so that Emacs has even (misguidedly)
toyed with the idea of getting rid of their
support.

But pray, please do elaborate?  What's so
special about tooltips here?

Please consider documenting it, whatever
it is - especially the "dangerous" bit.

And if this happens with tooltips then what
makes you think it's limited to the use of
`x-show-tip'?  Just what is `x-show-tip'-
specific?

> There are also some things you can put in `params'
> that will make Emacs crash, but I don't remember which.

Some things?  In 'params'?  (PARMS maybe?)  

Any crash is an Emacs bug (in C code).  Needs to
be fixed, regardless of who's authorized to use
`x-show-tip'.

If there are problems/gotchas/bugs/mysteries wrt
PARMS, or anything else your vague response is
meant to intimate, please fix or document them.

There's no difference in this regard between what
"core Emacs developers" need (and need to know)
when using `x-show-tip' and what other Emacs
developers need (i.e., users who develop 3rd-party
libraries) need.

Fix it or document it.  That's the proper response
for something useful that (you think) has problems.

Trying to wall it off with mysterious bluster is,
well, I won't say...

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> Lots of things can happen unpredictably with
> frames, per different window managers.

Not if you use `tooltip-show', I think.

> And invisible frames are used seldom - so
> much so that Emacs has even (misguidedly)
> toyed with the idea of getting rid of their
> support.
>
> But pray, please do elaborate?  What's so
> special about tooltips here?

Tooltips are made transient for the frame they are displayed in.
Compositing managers look at the WM_TRANSIENT_FOR property on tooltip
frames (which are a special kind of frame created without any widgets
that are always override redirect) to determine how to display the
tooltip.  Those frames are also displayed outside the usual redisplay
machinery, and only once, inside `x-show-tip'.

> Please consider documenting it, whatever
> it is - especially the "dangerous" bit.
>
> And if this happens with tooltips then what
> makes you think it's limited to the use of
> `x-show-tip'?  Just what is `x-show-tip'-
> specific?

That cannot happen with `tooltip-show'.

> Some things?  In 'params'?  (PARMS maybe?)  
>
> Any crash is an Emacs bug (in C code).  Needs to
> be fixed, regardless of who's authorized to use
> `x-show-tip'.

So crashing on some kinds of invalid bytecode is an Emacs bug, for that
same reason? 

> If there are problems/gotchas/bugs/mysteries wrt
> PARMS, or anything else your vague response is
> meant to intimate, please fix or document them.

`tool-bar-position' is one example of such a problematic frame
parameter, and there are many others, but I never enumerated all of
them.

Lisp code should _never_ manipulate tooltip frames.  They are special on
the C level in that many assumptions (such as there being a GTK or Xt
widget for each frame), or that the frame has at least one window that
isn't a "pseudo window" do not hold.  This is also why we bend over
backwards to not make tooltip frames visible to Lisp inside frame lists
and probably the display-buffer stuff as well.

> There's no difference in this regard between what
> "core Emacs developers" need (and need to know)
> when using `x-show-tip' and what other Emacs
> developers need (i.e., users who develop 3rd-party
> libraries) need.
>
> Fix it or document it.  That's the proper response
> for something useful that (you think) has problems.

It is documented.  The doc string says:

  This is an internal function; Lisp code should call `tooltip-show'.

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

[Drew Adams]

> > Lots of things can happen unpredictably with
> > frames, per different window managers.
> 
> Not if you use `tooltip-show', I think.

That's like saying "not if you use `forward-char'.
`tooltip-show' doesn't let you do what `x-show-tip'
does.  That's what this discussion is about (IMHO).

> > And invisible frames are used seldom - so
> > much so that Emacs has even (misguidedly)
> > toyed with the idea of getting rid of their
> > support.
> >
> > But pray, please do elaborate?  What's so
> > special about tooltips here?
> 
> Tooltips are made transient for the frame they are displayed in.
> Compositing managers look at the WM_TRANSIENT_FOR property on tooltip
> frames (which are a special kind of frame created without any widgets
> that are always override redirect) to determine how to display the
> tooltip.  Those frames are also displayed outside the usual redisplay
> machinery, and only once, inside `x-show-tip'.

If `tooltip-show' can use `x-show-tip' then so
can user code.  That's the point.  Whatever
guidance applies to _how_ `tooltip-show' uses
`x-show-tip' - whatever super-careful, wise,
limited use is deemed necessary or desirable,
can be made just as well by user code.

Make that guidance explicit, and please be sure
to make clear just what is really necessary and
what is extra, helpful, nice-to-know guidance.

That will add, not subtract, from Emacs.

> > Please consider documenting it, whatever
> > it is - especially the "dangerous" bit.
> >
> > And if this happens with tooltips then what
> > makes you think it's limited to the use of
> > `x-show-tip'?  Just what is `x-show-tip'-
> > specific?
> 
> That cannot happen with `tooltip-show'.

See above.  If that's the case then it means
that `tooltip-show' uses `x-show-tip' in a
particular way.  Document that guidance.
That's all that's needed (if really needed).

> > Some things?  In 'params'?  (PARMS maybe?)
> >
> > Any crash is an Emacs bug (in C code).  Needs to
> > be fixed, regardless of who's authorized to use
> > `x-show-tip'.
> 
> So crashing on some kinds of invalid bytecode is
> an Emacs bug, for that same reason?

Emacs has long held that _any_ crash is an
Emacs bug, yes.  If nothing else, Emacs should
catch the error and handle it more gracefully
than an out-and-out crash.

> > If there are problems/gotchas/bugs/mysteries wrt
> > PARMS, or anything else your vague response is
> > meant to intimate, please fix or document them.
> 
> `tool-bar-position' is one example of such a problematic frame
> parameter, and there are many others, but I never enumerated all of
> them.

Enumerate them.  Or not, if you can't.  That's
the proper approach.  What's good for the
`tooltip-show' goose's use of `x-show-tip' is
also good for user uses of `x-show-tip'.

> Lisp code should _never_ manipulate tooltip frames.
> They are special on
> the C level in that many assumptions (such as there being a GTK or Xt
> widget for each frame), or that the frame has at least one window that
> isn't a "pseudo window" do not hold.  This is also why we bend over
> backwards to not make tooltip frames visible to Lisp inside frame lists
> and probably the display-buffer stuff as well.

Again, whatever is sane for `tooltip-show's use
of `x-show-tip' is just as sane for user use of
it.  The same caveats and guidance, if any,
apply - equally.  There's nothing magical about
Lisp function `tooltip-show'.

> > There's no difference in this regard between what
> > "core Emacs developers" need (and need to know)
> > when using `x-show-tip' and what other Emacs
> > developers need (i.e., users who develop 3rd-party
> > libraries) need.
> >
> > Fix it or document it.  That's the proper response
> > for something useful that (you think) has problems.
> 
> It is documented.  The doc string says:
> 
>   This is an internal function; Lisp code should call `tooltip-show'.

That's misguided.  Let's not promulgate the old
user/developer divide from the 1960s.

That's not doc of how to use it.  If that's the
only thing you can say, then remove its use
from `tooltip-show' - the same considerations
apply.

If you have something useful to say, about how
`x-show-tip' should (let only must) be used,
then provide users with that guidance.  That's
what "fix it or document it" means.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> That's like saying "not if you use `forward-char'.
> `tooltip-show' doesn't let you do what `x-show-tip'
> does.  That's what this discussion is about (IMHO).

And what exactly doesn't `tooltip-show' let you do, that `x-show-tip'
can?

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

[Drew Adams]

> > `tooltip-show' doesn't let you do what `x-show-tip'
> > does.  That's what this discussion is about (IMHO).
> 
> And what exactly doesn't `tooltip-show' let you do, 
> that `x-show-tip'can?

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

Obviously.

That's a very specific, narrow call - it nails
down almost everything that `x-show-tip' takes
as an argument.

;; After getting the frame parameters from
;; `tooltip-frame-parameters', and perhaps
;; updating the foreground and background from
;; those of face `tooltip':
;;
(x-show-tip (propertize text 'face 'tooltip)
		 (selected-frame)
		 **THOSE-TOOLTIP-PARAMETERS**
		 tooltip-hide-delay
		 tooltip-x-offset
		 tooltip-y-offset))

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

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

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.

What's good for the goose is good for the gander.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

They can all be set by binding stuff around the call to `tooltip-show'.

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

[...]

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

So do it, because I'm not.  And before that happens, `x-show-tip' will
remain an internal function, joining the ranks of others such as
`xw-color-values', `x-internal-focus-input-context' and
`handle-save-session'.  Its arguments (or their meanings) might change
at any time, etc, etc.

> Really?  You really think so?

Yes, I do.

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

It does.  And if some problem comes up later, we can always change the
`tooltip-show' abstraction to avoid it.

> Bof.  More bluster.

Nonsense.  You can try resizing, or setting size hints on, or changing
the toolbar position of a tooltip frame, and it will either crash or
simply not work.

Not to mention that in some window systems there are simply no tooltip
frames at all.