bug#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

[martin rudalics]

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