GNU bug report logs - #14616
24.3.50; Excessive cursor movement on non-X Emacs

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs
Date: Mon, 05 Aug 2013 21:45:54 +0300

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Mon, 05 Aug 2013 20:22:17 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > This all sounds depressingly similar to what we found in bug #13864,
> > which was supposed to be fixed long ago.  Please use the technique
> > described in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13864#68 to
> > find out what code sets the frame's garbaged flag.  (The line numbers
> > cited in that message are different now, so be sure to use the current
> > ones.)
> 
> Ok, I've tried to reproduce this, and a trace is included below.
> 
> > Does the recipe you use involve more than one frame, somehow?
> 
> Hm...  I think I'm running only one frame.  I'm running with emacs -nw.
> Does that support more than one frame, somehow?  But, yes, my Gnus
> startup function has a call to
> 
> (make-frame '((name . "emacs") (left . 0) (top . 0) (user-position . t)))
> 
> in there.  I always start up two frames under X, but I didn't think that
> that call did anything under emacs -nw.

What does frame-list return after you start emacs -nw like that?

> Let's see.  I'll try to start Emacs (with -nw) without that call.
> 
> Aha!  Now there's no fluttering and no extra refreshes going on!  That
> might explain why I've never been able to reproduce this bug with a
> simple test case.
> 
> > The marked call to SET_FRAME_VISIBLE would set the frame's garbaged
> > flag.  The solution was to avoid doing that if FRAME is already the
> > top frame shown on that terminal (the EQ test and the comment before
> > it were added as part of fixing that bug).  Perhaps in your case this
> > logic is somehow not working?
> 
> Sounds likely.
> 
> Here's a couple seconds' worth of output from the recipe:
> 
> Hardware watchpoint 4: ((struct frame *) 0xc12be0)->garbaged
> 
> Old value = 1
> New value = 0
> clear_garbaged_frames () at xdisp.c:10729
> 10729		      f->resized_p = 0;
> Hardware watchpoint 4: ((struct frame *) 0xc12be0)->garbaged
> 
> Old value = 0
> New value = 1
> 0x0000000000420725 in do_switch_frame (frame=12659685, track=1, for_deletion=0, norecord=12571250) at frame.c:844
> 844		  SET_FRAME_VISIBLE (XFRAME (frame), 1);

We are close.  What I need to know now is what is 'frame" and what is
'top_frame' at this point.  You can define this as the watchpoint's
commands:

  > pp frame
  > pp top_frame
  > continue
  > end

Then run the recipe again, and let's see what this shows.

Thanks.

Previous Next

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