GNU bug report logs -
#14616
24.3.50; Excessive cursor movement on non-X Emacs
Previous Next
Reported by: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Date: Fri, 14 Jun 2013 08:02:02 UTC
Severity: normal
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #29 received at 14616 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: 14616 <at> debbugs.gnu.org
> Date: Tue, 25 Jun 2013 22:18:55 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Any progress with investigating this?
> >
> > Let me know if you need help.
>
> I do need help. I've been trying to follow the advice in the #13864 bug
> report, but the code has shifted quite a bit in the last two months, and
> I know virtually nothing about gdb, I'm afraid.
>
> Do you have a handy set of commands to start debugging this?
Let's see... The first set of instructions, at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13864#20, should still be
a good starting point. I repeat them below, indented (with one
important correction):
Could you please attach a debugger to Emacs, after starting the
server, but before opening the TTY frame with emacsclient, and set a
breakpoint like this:
(gdb) set height 0
(gdb) break update_frame_1
(gdb) commands
> p force_p
> p inhibit_id_p
> continue
> end
(gdb)
Then re-create the problem and see whether update_frame_1 is called
very frequently, and if so, what are the values of the 2 arguments
printed by the breakpoint commands above. (I don't know what is your
level of proficiency with GDB, so let me know if you need more
detailed instructions.)
Don't forget to invoke GDB from the src directory, and make sure that
it reads the .gdbinit file there, and does not reject it due to
security considerations.
If the above is not clear enough, let me know where you want me to
elaborate. (In case you didn't know, attaching a debugger means
running "gdb -p PID" where PID is the id of the Emacs process.)
The goal of the above is to see whether update_frame_1 is called with
high frequency, so that we could then understand why it is called and
why it redraws the same screen content again and again.
TIA
This bug report was last modified 11 years and 294 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.