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

[martin rudalics]

> 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

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

> I also wonder whether other places which seem to be similarly
> vulnerable hide bugs.  For example, what about frame-list:
[...]
> 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.

> IOW, instead a simple variable with a clear semantics, we now have a
> potential trap, whereby for every use of this variable we need to make
> non-trivial reasoning whether this issue could or couldn't hit us.
>
> 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 .  I've never run into problems like this because I always have
‘x-gtk-use-system-tooltips’ nil.

Please have a look at Dimitry's commit.  I think most parts of it were
good.  Maybe we should revive them.

martin