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

From: martin rudalics <[email-masked]>
Date: Thu, 09 Nov 2017 19:10:56 +0100

> What changes did you allude to here?  Can you point me to them?

   commit 20038f8ab75dd1551412a43cd58520c483c22921
   Author: Dmitry Antipov <[email-masked]>
   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