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

[Eli Zaretskii]

> Date: Thu, 09 Nov 2017 19:10:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: npostavs@users.sourceforge.net, agrambot@gmail.com, 
>  27647@debbugs.gnu.org, kaushal.modi@gmail.com
> 
>  > What changes did you allude to here?  Can you point me to them?
> 
>    commit 20038f8ab75dd1551412a43cd58520c483c22921
>    Author: Dmitry Antipov <dmantipov@yandex.ru>
>    Date:   Tue Jul 12 09:16:26 2016 +0300

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

>  > In general, using the same variable for two different purposes is
>  > exactly what I was talking about in the discussion of
>  > wait_reading_process_output discussion -- who could possibly keep all
>  > such factoids in memory, and avoid making such subtle mistakes as
>  > result?
> 
> Luckily we now have Noam on board to detect such mistakes.

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.

>  > Does this mean that in a GTK build, at some "opportune moment",
>  > frame-list will omit one frame from the list it returns, because that
>  > frame happens to show a tooltip at that very moment?
> 
> I think so.  With all sorts of funny implications.
> 
>  > Or what about a similar snippet in x-display-monitor-attributes-list?
>  > Is it in trouble as well?
> 
> If it gets called at the wrong moment, sure.

We should fix those places.

>  > I think we should get rid of this ambiguity on master.  Patches to
>  > that effect are welcome.
> 
> I'm afraid we have to get rid of all comparisons against tip_frame on
> the release branch first and check against the 'tooltip' frame parameter
> instead.

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

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

Thanks.