GNU bug report logs - #30399
27.0.50; tooltips are broken

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30399 in the body.
You can then email your comments to 30399 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; tooltips are broken
Date: Thu, 08 Feb 2018 23:26:29 +0100

I'm seeing buggy behavior with tooltips on master, and though I haven't
bisected with git, I see the problems starting with my first build after
this commit:

e462308f03..: Martin Rudalics 2018-01-18 Fix some tooltip related problems

and I don't see the problems in my builds before that commit.  My builds
are with GTK+; I haven't tried with another or no toolkit.

Here's the (expected) behavior prior to that commit (also seen in
current emacs-26):

0. emacs -Q
1. evaluate (tooltip-show "This is a test")
   => A GTK+-themed tooltip is displayed for 10 seconds or until there
   is an input event, then disappears. 
2. evaluate (x-show-tip "This is a test")
   => A GTK+-themed tooltip is displayed for 5 seconds or until there
   is an input event, then disappears.
3. evaluate (let (x-gtk-use-system-tooltips)
              (tooltip-show "This is a test"))
   => A non-toolkit tooltip is displayed for 10 seconds or until there
   is an input event, then disappears.
4. evaluate (let (x-gtk-use-system-tooltips)
              (x-show-tip "This is a test"))
   => A non-toolkit tooltip is displayed for 5 seconds or until there
   is an input event, then disappears.

And here's the buggy behavior (starting with step 2) I see on master
since the above commit:

0. emacs -Q
1. evaluate (tooltip-show "This is a test")
   => A GTK+-themed tooltip is displayed for 10 seconds or until there
   is an input event, then disappears.
2. evaluate (x-show-tip "This is a test")
   => A GTK+-themed tooltip is displayed and remains displayed, even if
   there are input events, until executing step 3 or repeating step 1.
3. evaluate (let (x-gtk-use-system-tooltips)
              (tooltip-show "This is a test"))
   => A non-toolkit tooltip is displayed and remains displayed, even if
   there are input events, until the end of the Emacs session (at least
   I haven't found a way to get rid of it); however, if the GTK+-themed
   tooltip from step 2 is still displayed when the above sexp is
   evaluated, then after 10 (not 5) seconds the GTK+-themed tooltip
   disappears (but the non-toolkit tooltip remains).
4. evaluate (let (x-gtk-use-system-tooltips)
              (x-show-tip "This is a test"))
   => A non-toolkit tooltip is displayed and remains displayed, even if
   there are input events, until the end of the Emacs session AFAICT; if
   the tooltip from step 3 is still displayed when the above sexp is
   evaluated, it is just moved by this step but does not disappear, and
   if the GTK+-themed tooltip from step 2 is still displayed that
   tooltip also remains displayed (unlike in step 3).

I tried stepping through Fx_show_tip in gdb while executing step 1 and
again with step 2 in current master.  In both cases the GTK+-themed
tooltip appears, the code path jumps to start_timer, runs a timer, calls
x-hide-tip and then the function returns; in step 1, on continuing, the
tooltip disappears, but in step 2, on continuing, the tooltip remains.
Then I tried stepping through x_hide_tip, but the breakpoint was hit
before the tooltip was displayed and on continuing until the command
loop was again accessible, any input immediate hit the breakpoint
again.  So I probably cannot debug this further without guidance.

In GNU Emacs 27.0.50 (build 17, x86_64-pc-linux-gnu, GTK+ Version 3.22.18)
 of 2018-02-08 built on rosalinde
Repository revision: a710f8aa61ca73054109dc4f926d1ac6aabdd849
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Linux From Scratch

Configured using:
 'configure --with-xwidgets 'CFLAGS=-Og -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Message #8 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Fri, 09 Feb 2018 10:53:30 +0100

[Message part 1 (text/plain, inline)]

> And here's the buggy behavior (starting with step 2) I see on master
> since the above commit:
>
> 0. emacs -Q
> 1. evaluate (tooltip-show "This is a test")
>     => A GTK+-themed tooltip is displayed for 10 seconds or until there
>     is an input event, then disappears.
> 2. evaluate (x-show-tip "This is a test")
>     => A GTK+-themed tooltip is displayed and remains displayed, even if
>     there are input events, until executing step 3 or repeating step 1.

This is due to a rather silly omission which should have already
defeated a feature in Emacs 26 when calling 'x-show-tip' (you've been
warned - Lisp code should call 'tooltip-show').

> 3. evaluate (let (x-gtk-use-system-tooltips)
>                (tooltip-show "This is a test"))
>     => A non-toolkit tooltip is displayed and remains displayed, even if
>     there are input events, until the end of the Emacs session (at least
>     I haven't found a way to get rid of it); however, if the GTK+-themed
>     tooltip from step 2 is still displayed when the above sexp is
>     evaluated, then after 10 (not 5) seconds the GTK+-themed tooltip
>     disappears (but the non-toolkit tooltip remains).
> 4. evaluate (let (x-gtk-use-system-tooltips)
>                (x-show-tip "This is a test"))
>     => A non-toolkit tooltip is displayed and remains displayed, even if
>     there are input events, until the end of the Emacs session AFAICT; if
>     the tooltip from step 3 is still displayed when the above sexp is
>     evaluated, it is just moved by this step but does not disappear, and
>     if the GTK+-themed tooltip from step 2 is still displayed that
>     tooltip also remains displayed (unlike in step 3).

Let-binding 'x-gtk-use-system-tooltips' is a more delicate issue.  As
a rule, options should never be let-bound but since the customizer is
always right we'll probably have to fix this as well.

Please try the attached fix.  And please test it also with the inverse
scenario

(setq x-gtk-use-system-tooltips nil)
(let ((x-gtk-use-system-tooltips t))
  (tooltip-show "Test"))

Thanks, martin

[gtk-tooltip.diff (text/plain, attachment)]

Message #11 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 30399 <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Fri, 09 Feb 2018 11:49:30 +0100

On Fri, 09 Feb 2018 10:53:30 +0100 martin rudalics <rudalics <at> gmx.at> wrote:

>> And here's the buggy behavior (starting with step 2) I see on master
>> since the above commit:
>>
>> 0. emacs -Q
>> 1. evaluate (tooltip-show "This is a test")
>>     => A GTK+-themed tooltip is displayed for 10 seconds or until there
>>     is an input event, then disappears.
>> 2. evaluate (x-show-tip "This is a test")
>>     => A GTK+-themed tooltip is displayed and remains displayed, even if
>>     there are input events, until executing step 3 or repeating step 1.
>
> This is due to a rather silly omission which should have already
> defeated a feature in Emacs 26 when calling 'x-show-tip' (you've been
> warned - Lisp code should call 'tooltip-show').

I know, and the code that revealed this bug does use tooltip-show; but
the above difference between them puzzled me, since tooltip-show is a
wrapper around x-show-tip.

>> 3. evaluate (let (x-gtk-use-system-tooltips)
>>                (tooltip-show "This is a test"))
>>     => A non-toolkit tooltip is displayed and remains displayed, even if
>>     there are input events, until the end of the Emacs session (at least
>>     I haven't found a way to get rid of it); however, if the GTK+-themed
>>     tooltip from step 2 is still displayed when the above sexp is
>>     evaluated, then after 10 (not 5) seconds the GTK+-themed tooltip
>>     disappears (but the non-toolkit tooltip remains).
>> 4. evaluate (let (x-gtk-use-system-tooltips)
>>                (x-show-tip "This is a test"))
>>     => A non-toolkit tooltip is displayed and remains displayed, even if
>>     there are input events, until the end of the Emacs session AFAICT; if
>>     the tooltip from step 3 is still displayed when the above sexp is
>>     evaluated, it is just moved by this step but does not disappear, and
>>     if the GTK+-themed tooltip from step 2 is still displayed that
>>     tooltip also remains displayed (unlike in step 3).
>
> Let-binding 'x-gtk-use-system-tooltips' is a more delicate issue.  As
> a rule, options should never be let-bound but since the customizer is
> always right we'll probably have to fix this as well.

I generally use the default value of x-gtk-use-system-tooltips, but for
appointments I use a custom tooltip, which AFAICT requires setting
x-gtk-use-system-tooltips to nil.  Is there some way to achieve this
without let-binding (or using setq twice within the function defining
the appointment tooltip)?

> Please try the attached fix.  

It restores the previous behavior; thanks!

>                               And please test it also with the inverse
> scenario
>
> (setq x-gtk-use-system-tooltips nil)
> (let ((x-gtk-use-system-tooltips t))
>   (tooltip-show "Test"))

This also works as expected, i.e., within the let-binding the tooltip is
the GTK+-themed one, and outside of the let-binding it's the not-toolkit
tooltip.

Thanks for the quick fix.

Steve Berman

Message #14 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Stephen Berman
 <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: RE: bug#30399: 27.0.50; tooltips are broken
Date: Fri, 9 Feb 2018 07:41:55 -0800 (PST)

> This is due to a rather silly omission which should have already
> defeated a feature in Emacs 26 when calling 'x-show-tip' (you've
> been warned - Lisp code should call 'tooltip-show').

That warning sounds very bad to me.  It's vague, however,
so forgive me if I'm overreacting.

I have 4 libraries that will presumably break completely
if `x-show-tip' is defeated or is no longer available.
`tooltip-show' does NOT do the same thing and will not
work (AFAICT) for what I use `x-show-tip' for.

The libraries are `pp+.el', `apu.el', `modeline-char.el',
and `showkey.el'.  They are all available on Emacs Wiki,
Elisp Area.

https://www.emacswiki.org/emacs?action=elisp-area;context=0

`tooltip-show' constrains its call of `x-show-tip' to
only one particular behavior/appearance, etc.  Replacing
the latter function with just the former would be like
replacing the general function `goto-char' a limited one
such as `beginning-of-line'.  `x-show-tip' is much more
general than `tooltip-show'.

Here's a typical call:

(x-show-tip (propertize
              cmd-desc
              'face
              `(:foreground "red"
                :height ,showkey-tooltip-height))
            nil
            nil
            showkey-tooltip-timeout)

Message #17 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 
 Stephen Berman <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Sat, 10 Feb 2018 10:47:46 +0100

>> This is due to a rather silly omission which should have already
>> defeated a feature in Emacs 26 when calling 'x-show-tip' (you've
>> been warned - Lisp code should call 'tooltip-show').
>
> That warning sounds very bad to me.  It's vague, however,
> so forgive me if I'm overreacting.

It's up to you to ignore warnings.

> Here's a typical call:
>
> (x-show-tip (propertize
>                cmd-desc
>                'face
>                `(:foreground "red"
>                  :height ,showkey-tooltip-height))
>              nil
>              nil
>              showkey-tooltip-timeout)

Make sure to use (selected-frame) as second argument for Emacs < 27.
nil is broken but you might not notice it.

martin

Message #22 received at 30399-close <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 30399-close <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Sat, 10 Feb 2018 10:47:19 +0100

> I know, and the code that revealed this bug does use tooltip-show; but
> the above difference between them puzzled me, since tooltip-show is a
> wrapper around x-show-tip.

Good catch - that bug was with us for quite some time.

> I generally use the default value of x-gtk-use-system-tooltips, but for
> appointments I use a custom tooltip, which AFAICT requires setting
> x-gtk-use-system-tooltips to nil.  Is there some way to achieve this
> without let-binding (or using setq twice within the function defining
> the appointment tooltip)?

Let-binding is certainly more convenient in this regard.  But a
package should (IMO) make it customizable whether the user value of
'x-gtk-use-system-tooltips' should be applied for appointments too.

> Thanks for the quick fix.

Thanks for the very helpful report.

Bug closed, martin

Message #25 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Stephen Berman
 <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: RE: bug#30399: 27.0.50; tooltips are broken
Date: Sat, 10 Feb 2018 08:39:02 -0800 (PST)

>>> This is due to a rather silly omission which should have already
>>> defeated a feature in Emacs 26 when calling 'x-show-tip' (you've
>>> been warned - Lisp code should call 'tooltip-show').
>>
>> That warning sounds very bad to me.  It's vague, however,
>> so forgive me if I'm overreacting.
> 
> It's up to you to ignore warnings.

I'm objecting to the possible change in support forewarned
by your warning, not the fact of the warning's existence.

Can you clarify the warning, please?

If there is a reason to replace `x-show-tip', can you not
replace it with something that is just as general?  Why
would we take away something that lets you specify the
appearance and behavior, replacing it by something that
just hard-codes properties etc.?

I hope I'm just missing something (i.e., misunderstanding).

>  > (x-show-tip (propertize
>  >                cmd-desc
>  >                'face
>  >                `(:foreground "red"
>  >                  :height ,showkey-tooltip-height))
>  >              nil
>  >              nil
>  >              showkey-tooltip-timeout)
> 
> Make sure to use (selected-frame) as second argument for
> Emacs < 27.  nil is broken but you might not notice it.

Thank you.  I didn't know that.  And you're right that
I haven't noticed it, so far.

Can you please say what the brokenness is?  Is there
a bug # for that, so we can learn about the brokenness
that we might not notice?  Thx.

Message #28 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 
 Stephen Berman <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Sun, 11 Feb 2018 10:36:15 +0100

> Can you clarify the warning, please?

That when the behavior of 'x-show-tip' changes, applications will
have to adapt.

> If there is a reason to replace `x-show-tip', can you not
> replace it with something that is just as general?  Why
> would we take away something that lets you specify the
> appearance and behavior, replacing it by something that
> just hard-codes properties etc.?

Currently there are no plans to replace 'x-show-tip' AFAICT.

>> Make sure to use (selected-frame) as second argument for
>> Emacs < 27.  nil is broken but you might not notice it.
>
> Thank you.  I didn't know that.  And you're right that
> I haven't noticed it, so far.
>
> Can you please say what the brokenness is?  Is there
> a bug # for that, so we can learn about the brokenness
> that we might not notice?  Thx.

Internally, Emacs tries to not delete/recreate a tooltip frame when
the text of the tooltip remains the same and only its position
changes.  This optimization may get broken when using nil as the
second argument.  As mentioned, you probably won't notice it.

martin

Message #31 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Stephen Berman
 <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: RE: bug#30399: 27.0.50; tooltips are broken
Date: Sun, 11 Feb 2018 09:23:59 -0800 (PST)

>  > Can you clarify the warning, please?
> 
> That when the behavior of 'x-show-tip' changes,
> applications will have to adapt.

That's even more vague - not a clarification at all.
What is the behavior change?  What kind of adaptation
are you hinting at?

>  > If there is a reason to replace `x-show-tip', can you not
>  > replace it with something that is just as general?  Why
>  > would we take away something that lets you specify the
>  > appearance and behavior, replacing it by something that
>  > just hard-codes properties etc.?
> 
> Currently there are no plans to replace 'x-show-tip' AFAICT.

Let's not quibble over the word "replace", please.

You imply that "the behavior of 'x-show-tip'" will
change.  That's what I'm asking about, in talking
about "replacement".

You also said that we should not use 'x-show-tip'
but should use only `tooltip-show', which is much
more limited - not a substitute for 'x-show-tip'
at all.

The question is, if `x-tool-tip' is not expected
to be replaced, but it is expected to change, just
_how_ is it expected to change?

Will we be able to do with the "new" `x-show-tip',
what we can do with it now, even if we must "adapt"
in some way to be able to do that?

You are being quite vague, it seems.  You make a
pronouncement that we should not use the function,
but also that it will change - somehow.

The real question is not the words to name the
impending change or replacement that you warn us
about.

The question is how, after the change/replacement,
to get done everything we can do now with that
function.

Message #34 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 
 Stephen Berman <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: Re: bug#30399: 27.0.50; tooltips are broken
Date: Mon, 12 Feb 2018 10:26:40 +0100

>> That when the behavior of 'x-show-tip' changes,
>> applications will have to adapt.
>
> That's even more vague - not a clarification at all.
> What is the behavior change?  What kind of adaptation
> are you hinting at?

That if for some reason the behavior of that function must be changed,
its callers may have to change too.

>> Currently there are no plans to replace 'x-show-tip' AFAICT.
>
> Let's not quibble over the word "replace", please.
>
> You imply that "the behavior of 'x-show-tip'" will
> change.  That's what I'm asking about, in talking
> about "replacement".

'x-show-tip' had a bug that has been hopefully fixed.  I did not imply
anything else.

> You also said that we should not use 'x-show-tip'
> but should use only `tooltip-show', which is much
> more limited - not a substitute for 'x-show-tip'
> at all.

I'm using 'x-show-tip' in my private code, so why should I say such a
thing.

> The question is, if `x-tool-tip' is not expected
> to be replaced, but it is expected to change, just
> _how_ is it expected to change?
>
> Will we be able to do with the "new" `x-show-tip',
> what we can do with it now, even if we must "adapt"
> in some way to be able to do that?

Hopefully so.

> You are being quite vague, it seems.  You make a
> pronouncement that we should not use the function,
> but also that it will change - somehow.

I did neither the former nor the latter.

> The real question is not the words to name the
> impending change or replacement that you warn us
> about.
>
> The question is how, after the change/replacement,
> to get done everything we can do now with that
> function.

Let's see to that when we're there.

martin

Message #37 received at 30399 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, Stephen Berman
 <stephen.berman <at> gmx.net>, 30399 <at> debbugs.gnu.org
Subject: RE: bug#30399: 27.0.50; tooltips are broken
Date: Mon, 12 Feb 2018 06:43:57 -0800 (PST)

>  > You imply that "the behavior of 'x-show-tip'" will
>  > change.  That's what I'm asking about, in talking
>  > about "replacement".
> 
> 'x-show-tip' had a bug that has been hopefully fixed.
> I did not imply anything else.

That's good to hear.  That was not clear to me.

>  > You also said that we should not use 'x-show-tip'
>  > but should use only `tooltip-show', which is much
>  > more limited - not a substitute for 'x-show-tip'
>  > at all.
> 
> I'm using 'x-show-tip' in my private code, so why
> should I say such a thing.

I certainly got the wrong impression from what you
wrote, then.  Thanks for clarifying.

>  > The question is, if `x-tool-tip' is not expected
>  > to be replaced, but it is expected to change, just
>  > _how_ is it expected to change?
>  >
>  > Will we be able to do with the "new" `x-show-tip',
>  > what we can do with it now, even if we must "adapt"
>  > in some way to be able to do that?
> 
> Hopefully so.

Very good to hear.  Glad I asked for clarification,
and thank you for clarifying.  None of what you say now
was clear (to me) from your previous msgs in this thread.
Sorry, if the misunderstanding was my fault here.

And thanks for fixing the `x-show-tip' bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.