[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30399: 27.0.50; tooltips are broken
From: |
Stephen Berman |
Subject: |
bug#30399: 27.0.50; tooltips are broken |
Date: |
Fri, 09 Feb 2018 11:49:30 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
On Fri, 09 Feb 2018 10:53:30 +0100 martin rudalics <rudalics@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
- bug#30399: 27.0.50; tooltips are broken, Stephen Berman, 2018/02/08
- bug#30399: 27.0.50; tooltips are broken, martin rudalics, 2018/02/09
- bug#30399: 27.0.50; tooltips are broken,
Stephen Berman <=
- bug#30399: 27.0.50; tooltips are broken, Drew Adams, 2018/02/09
- bug#30399: 27.0.50; tooltips are broken, martin rudalics, 2018/02/10
- bug#30399: 27.0.50; tooltips are broken, Drew Adams, 2018/02/10
- bug#30399: 27.0.50; tooltips are broken, martin rudalics, 2018/02/11
- bug#30399: 27.0.50; tooltips are broken, Drew Adams, 2018/02/11
- bug#30399: 27.0.50; tooltips are broken, martin rudalics, 2018/02/12
- bug#30399: 27.0.50; tooltips are broken, Drew Adams, 2018/02/12