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

[martin rudalics]

> Not exactly.  tip_frame should be nil when GTK pops a native tooltip,
> then tip_frame will get its simple semantics back.

x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip.

> If GTK needs to
> stash the original frame, to be used to hide the tooltip, it should
> use a separate variable (or a struct frame member), also with simple
> semantics.  Two variables with simple semantics are much better than
> one with a subtly complex one.  Don't you agree?

IIUC GTK doesn't need the original frame.  But it sets tooltip_frame to
it so Fx_show_tip and friends can base their decisions on it.  Look at
occurrences of FRAMEP (tip_frame) and FRAME_LIVE_P (XFRAME (tip_frame)).
They pass because for GTK tip_frame is a live frame associated with the
tooltip.  Jan tried hard to leave the native tooltip code untouched.

> That timer was at the base of the proposed solution, AFAIU.  So if you
> dislike it, you dislike the idea itself.

I don't dislike the timer.  I dislike the idea to put it on a frame
parameter.

>> but maybe there really is no better solution.
>
> Sorry, I refuse to believe that.

Where would you put it?

>> Anyway, replacing the global variable and the frame parameter stuff
>> by a one-bit per frame slot should be enough for fixing the mess at
>> hand.
>
> Exactly.  So why we need the rest of the complexity in that patch?

Simply because I don't know whether the rest is more complex than what's
needed to fix the mess.

martin