From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#14616: 24.3.50; Excessive cursor movement on non-X Emacs Date: Sat, 03 Aug 2013 16:32:10 +0300 Message-ID: <83ehaayk6d.fsf@gnu.org> References: <83y5a0ka99.fsf@gnu.org> <83ip10hlyr.fsf@gnu.org> <83hafqz8uo.fsf@gnu.org> <83wqo8vvyb.fsf@gnu.org> <83fvuuws3k.fsf@gnu.org> <83mwp1z7dm.fsf@gnu.org> <83a9l0yxom.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1375536802 28166 80.91.229.3 (3 Aug 2013 13:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Aug 2013 13:33:22 +0000 (UTC) Cc: 14616@debbugs.gnu.org To: Lars Magne Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 03 15:33:19 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 1V5bxP-0004ka-AO for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2013 15:33:19 +0200 Original-Received: from localhost ([::1]:49182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bxO-0006Io-VC for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2013 09:33:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bxF-0006IW-LR for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:33:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5bx9-0008Oq-Tt for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:33:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43560) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bx9-0008OU-R3 for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:33:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V5bx9-0005Qk-7Z for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:33:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Aug 2013 13:33:02 +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: X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.137553676320822 (code B ref -1); Sat, 03 Aug 2013 13:33:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Aug 2013 13:32:43 +0000 Original-Received: from localhost ([127.0.0.1]:37876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V5bwo-0005Pl-3f for submit@debbugs.gnu.org; Sat, 03 Aug 2013 09:32:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37718) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V5bwg-0005PH-8L for submit@debbugs.gnu.org; Sat, 03 Aug 2013 09:32:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5bwU-0008AY-0e for submit@debbugs.gnu.org; Sat, 03 Aug 2013 09:32:28 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:48503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bwT-0008AU-Tt for submit@debbugs.gnu.org; Sat, 03 Aug 2013 09:32:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bwO-0006G0-0u for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:32:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5bwI-00088S-7l for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:32:15 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:63796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5bwI-000889-0d for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 09:32:10 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MQY00F00IWRG900@a-mtaout22.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2013 16:32:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MQY00E1ZIXJPEC0@a-mtaout22.012.net.il>; Sat, 03 Aug 2013 16:32:08 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). 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:76931 Archived-At: > From: Lars Magne Ingebrigtsen > Cc: bug-gnu-emacs@gnu.org > Date: Sat, 03 Aug 2013 15:00:01 +0200 > > Hm... Is wait_reading_process_output triggering this? It triggers redisplay, yes, but that's not the problem. The problem is here: > Hardware watchpoint 4: -location current_row->enabled_p > > Old value = 1024 > New value = 0 > clear_glyph_matrix_rows (matrix=0xc16260, start=23, end=25) at dispnew.c:730 > 730 for (; start < end; ++start) > #0 clear_glyph_matrix_rows (matrix=0xc16260, start=23, end=25) at dispnew.c:730 > #1 0x0000000000412a60 in clear_glyph_matrix (matrix=0xc16260) at dispnew.c:749 > #2 0x0000000000412f52 in clear_current_matrices (f=0xc12be0) at dispnew.c:797 > #3 0x0000000000444c1b in clear_garbaged_frames () at xdisp.c:10726 > #4 0x00000000004497de in redisplay_internal () at xdisp.c:13047 Emacs thinks that the frame is garbaged, so it clears the enabled_p flag of all of the screen lines on that frame, at the beginning of each redisplay cycle. 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.) Does the recipe you use involve more than one frame, somehow? The problem fixed in bug #13864 was in this snippet from frame.c: if (FRAME_TERMCAP_P (XFRAME (frame)) || FRAME_MSDOS_P (XFRAME (frame))) { Lisp_Object top_frame = FRAME_TTY (XFRAME (frame))->top_frame; /* Don't mark the frame garbaged and/or obscured if we are switching to the frame that is already the top frame of that TTY. */ if (!EQ (frame, top_frame)) { if (FRAMEP (top_frame)) /* Mark previously displayed frame as now obscured. */ SET_FRAME_VISIBLE (XFRAME (top_frame), 2); SET_FRAME_VISIBLE (XFRAME (frame), 1); <<<<<<<<<<<<<<<<<<<< } FRAME_TTY (XFRAME (frame))->top_frame = frame; } 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?