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

Previous Next

Full log

Message #59 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: Thu, 01 Aug 2013 19:46:29 +0300

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: bug-gnu-emacs <at> gnu.org
> Date: Thu, 01 Aug 2013 12:41:29 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > It doesn't actually redraw the lines, at least not on my system.  What
> > it does is examine each screen line in the 'desired' glyph matrix (a
> > structure that describes what _should_ be on the screen) with the
> > corresponding line in the 'current' glyph matrix (which describes what
> > _is_ on the screen).
> 
> I see.  Is there a better place to put the trace so that it'll only
> trigger when something is actually redrawn?  That would make poking
> around trying to trigger the bug easier...

The functions that actually cause Emacs to write something to the
terminal are write_glyphs, insert_glyphs, delete_glyphs, and
cursor_to and clear_end_of_line.  You will see them called from
update_frame_line in several places.  Either put a breakpoint at each
of those places, with the following breakpoint commands:

 (gdb) commands
   > continue
   > end

or put breakpoints _in_ those functions, with the following
breakpoint commands:

 (gdb) commands
   > bt 2
   > continue
   > end

The "bt 2" part will allow to see with what vpos argument was
update_frame_line called, so it will be easy to see which portions of
the screen we are redrawing.  You are looking for calls that
successively redraw several screen lines, preferably in the text area,
not the mode line.

Thanks.

Previous Next

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