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

[martin rudalics]

> Thanks.  It's a jumbo changeset, hard to see the forest for the trees.

It worked everywhere but for that Mac case.

> The challenge is not to make such mistakes in the first place.  We
> could easily let it slip into Emacs 26.1, if we were less lucky.

We were lucky that you wrote the native line numbers code that revealed
the problem, that Alex mentioned that only ‘x-gtk-use-system-tooltips’
would reveal it and that Noam found the cause.  But we also would have
never known about this particular bug if we had left in Dmitry's code.

> We should fix those places.

I see you have done that already, thanks.  I can't reasonably do any
work here because regular builds of the release branch still fail.

> Not if we always either put in that variable either the tooltip frame
> or nil, never any other frame.  IOW, if we make it an innocent
> variable with simple semantics again, and track the frame GTK needs
> "by other means".

If the semantics of tip_frame non-nil is

"The frame of a currently visible tooltip."

and for a GTK build the "currently visible tooltip" has no frame, then
we have no simple semantics.  It means that for GTK we always need an
additional test like that for a 'tooltip' frame parameter.  Don't you
agree?

>> Please have a look at Dimitry's commit.  I think most parts of it were
>> good.  Maybe we should revive them.
>
> Maybe I'm missing something, but I don't understand why the changes
> for this have to be so complex and invasive.  But I'll review any
> specific proposal for fixing this mess.

He didn't want to change only "this".  His was a pretty comprehensive
solution for many problems in this area.  The only thing I disliked was
that 'tooltip-timer' parameter, but maybe there really is no better
solution.  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.

martin