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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
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 17:57:07 +0200

> Date: Thu, 09 Nov 2017 08:28:55 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 27647 <at> debbugs.gnu.org, Kaushal Modi <kaushal.modi <at> gmail.com>
> 
> And yes, we wouldn't have had that problem if we had left in (parts
> of) the code Dmitry Antipov installed some time ago where "The goal
> was to avoid tricky global variables".

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

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?

I also wonder whether other places which seem to be similarly
vulnerable hide bugs.  For example, what about frame-list:

  DEFUN ("frame-list", Fframe_list, Sframe_list,
	 0, 0, 0,
	 doc: /* Return a list of all live frames.  */)
    (void)
  {
    Lisp_Object frames;
    frames = Fcopy_sequence (Vframe_list);
  #ifdef HAVE_WINDOW_SYSTEM
    if (FRAMEP (tip_frame))
      frames = Fdelq (tip_frame, frames);
  #endif
    return frames;
  }

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?

Or what about a similar snippet in x-display-monitor-attributes-list?
Is it in trouble as well?

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.

Previous Next

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