GNU bug report logs - #27647
26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus

Previous Next

Package: emacs;

Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>

Date: Mon, 10 Jul 2017 20:55:02 UTC

Severity: normal

Tags: patch

Found in version 26.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #139 received at 27647 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27647 <at> debbugs.gnu.org, kaushal.modi <at> gmail.com, agrambot <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#27647: 26.0.50; Line numbers implemented natively disappear
 momentarily when frame out of focus
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 <dmantipov <at> 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





This bug report was last modified 7 years and 242 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.