GNU bug report logs -
#30399
27.0.50; tooltips are broken
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Thu, 8 Feb 2018 22:27:01 UTC
Severity: normal
Found in version 27.0.50
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#30399: 27.0.50; tooltips are broken
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 30399 <at> debbugs.gnu.org.
--
30399: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30399
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> 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 part 3 (message/rfc822, inline)]
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
This bug report was last modified 7 years and 97 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.