GNU bug report logs -
#27647
26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus
Previous Next
Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>
Date: Mon, 10 Jul 2017 20:55:02 UTC
Severity: normal
Tags: patch
Found in version 26.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>> > No, it's because x-show-tip _needs_ a frame on which to pop up the
>> > tooltip.
>>
>> Only to pass a display info to x_create_tip_frame and to do the
>> last_frame rigmarole.
>
> Like with any other frame we create, no?
I once thought of doing away with x_create_tip_frame, putting all
tooltip specific parameters into ‘tooltip-frame-parameters’ and let
people shoot themselves in their feet when overriding them. Might be
still worth the hassle.
> Besides, GTK needs the frame to stash away the widget.
That's a vice of GTK. We should cure that.
>> But I do not anywhere see a dependency that would trigger the
>> deletion of a tip frame when the frame on which it popped up gets
>> deleted.
>
> x-show-tip starts a timer that calls x-hide-tip when the timer
> expires. And x-hide-tip deletes the tip frame.
I was thinking of a scenario like ...
(let ((tooltip-hide-delay 1000)
(frame (make-frame)))
(select-frame frame)
(tooltip-show ".....")
(delete-frame frame))
... but try for yourself. Unless you have a better idea I'll make
x_create_tip_frame call make_frame_without_minibuffer. Any clues why
the above doesn't crash Emacs <= 24?
>> So passing the frame is inherently needed only for the
>> sake of xg_show_tooltip, xg_hide_tooltip and xg_free_frame_widgets. Or
>> am I missing something?
>
> And for the rigmarole.
I'll try to get rid of that.
martin
This bug report was last modified 7 years and 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.