From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs Date: Fri, 19 Jul 2013 17:31:32 +0200 Message-ID: References: <83y5a0ka99.fsf@gnu.org> <83ip10hlyr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374247945 22307 80.91.229.3 (19 Jul 2013 15:32:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2013 15:32:25 +0000 (UTC) Cc: 14616@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 19 17:32:26 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V0CfE-0006A9-4i for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jul 2013 17:32:12 +0200 Original-Received: from localhost ([::1]:37173 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0CfD-0006Qj-Gr for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Jul 2013 11:32:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0Cf8-0006QZ-79 for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2013 11:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0Cf4-0004Qn-97 for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2013 11:32:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0Cf4-0004Qj-6Q for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2013 11:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V0Cf3-0004hQ-Sx for bug-gnu-emacs@gnu.org; Fri, 19 Jul 2013 11:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Magne Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Jul 2013 15:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14616 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14616-submit@debbugs.gnu.org id=B14616.137424790818031 (code B ref 14616); Fri, 19 Jul 2013 15:32:01 +0000 Original-Received: (at 14616) by debbugs.gnu.org; 19 Jul 2013 15:31:48 +0000 Original-Received: from localhost ([127.0.0.1]:37659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V0Cep-0004gk-NR for submit@debbugs.gnu.org; Fri, 19 Jul 2013 11:31:48 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:38716) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V0Cem-0004gV-T5 for 14616@debbugs.gnu.org; Fri, 19 Jul 2013 11:31:45 -0400 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V0Cea-0004tS-Au; Fri, 19 Jul 2013 17:31:32 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEUfHh3AwMAFBAQEAgP/ //8GBQQEAwIDAQG/nq4VAAACFklEQVQ4jV2TwY7jIAyGndFwByl7rxzB3IO250biAVK05L5Uca4j rZS8/tqQTJtySBAfP79tDAQZqS2/MDQGVCoDyoKq6+E26DOAHRgGdR3rkt5PaodbEcQDmDDIuuEt VTDbAxhTJbuD3RUclG5aE7TZLaL9AUGPTavMflTeQRiAl0ajiiK7ifAAQaURQnWYEv07AOemoC1g oojL+gRB81TFC3xgGT/AqIZBgjESpYgWnoJWgGo/Zpvci6LkrmyjP2xKXd8/geSicEyICWd6AaX8 Ule0iP4NRCsAM3Z4AkO0JdTcXc+KoZyErn/4N0WyfEeRLbrfb4CvLsphF3MCt3LbmC3ewxvgWLkc idvpBRhOQ5Lgex3DSaHFAsV/PCnCoEq0/LFjewK/UICVgO9wnC+fm1hjkvzHAgbNbqZtbxGjkzR8 BdIyclNGxVJBRx4vDHT0s23ZWpXNDCIJYP0146fcumz32LlOwKCcX7L7EwyYUiZ0D99zMyiM2fv+ PnAPSki1iAykbJ6uF7bCUpAUK+A2RXpkdtfcajkKcI9eFHwqof0Uc+61FFkhgLIjIsetbiBilqeR OTgLXwXQzLkqdBnn5KrH6hYBZOWB7S9W/vC1bCsx+6sBGgAN8ucJuAU3Wrbtm+ejgucgmrZt2aiO meNgz4wJaN1krAvxt8A0TeKxvQ5evvL+8nDOoLvWE0WxvID1sLLpPwuNGKVrO4y7AAAAAElFTkSu QmCC X-Now-Playing: Winston Tong's _Theoretically Chinese_: "Endgame" X-Hashcash: 1:23:130719:14616@debbugs.gnu.org::zB1FjDVLbXYgRpku:0000000000000000000000000000000000000000525r X-Hashcash: 1:23:130719:eliz@gnu.org::VKueKxJKkNa0nXNC:000009hNf In-Reply-To: <83ip10hlyr.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Jun 2013 19:32:12 +0300") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-MailScanner-ID: 1V0Cea-0004tS-Au MailScanner-NULL-Check: 1374852692.76852@a2y8v/UyGM84cUxUZeDMIg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76492 Archived-At: Eli Zaretskii writes: > 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) Thanks for the recipe. The first thing that I notice is that after starting Gnus, and letting Gnus settle (so there's not screen updates at all), I get the following: Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $443 = true $444 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $445 = true $446 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $447 = true $448 = false Once per second. So it seems like something is making the update fire regularly, but not very intensively. Nothing that I'm able to detect happens on the screen -- I have no clocks or anything altering anything. Now, for the real bug. When I then select an article in Gnus, this starts firing like crazy: Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16335 = true $16336 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16337 = true $16338 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16339 = true $16340 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16341 = true $16342 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16343 = true $16344 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $16345 = true $16346 = false [...] Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $17071 = true $17072 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $17073 = true $17074 = false Breakpoint 3, update_frame_1 (f=0xc12be0, force_p=true, inhibit_id_p=false) at dispnew.c:4445 4445 struct glyph_matrix *current_matrix = f->current_matrix; $17075 = true $17076 = false So it fired about er seven thousand times? When Gnus selects an article in these groups, a lot of network traffic is fired off as it uses `url-retrieve' to pre-fetch images. So my uninformed guess would be that something in the network code is telling Emacs that the display is dirty and needs to be repainted. Does this output tell you anything, or should I put the breakpoints somewhere else? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/