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#10304: 24.0.92: display but Date: Sat, 07 Jan 2012 10:48:32 +0200 Message-ID: <8362gnhp9b.fsf@gnu.org> References: <8762hihrj7.fsf@live.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325926214 15799 80.91.229.12 (7 Jan 2012 08:50:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2012 08:50:14 +0000 (UTC) Cc: 10304@debbugs.gnu.org, yagnesh@live.com To: Lars Magne Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 07 09:50:10 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjRyb-0003CL-9x for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2012 09:50:09 +0100 Original-Received: from localhost ([::1]:55385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjRya-0008IH-Lh for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2012 03:50:08 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjRyX-0008H9-Hu for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 03:50:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjRyU-0005Xc-4y for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 03:50:05 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjRyT-0005XV-Tw for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2012 03:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RjRyU-0005a0-8U; Sat, 07 Jan 2012 03:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Sat, 07 Jan 2012 08:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10304 X-GNU-PR-Package: emacs,gnus X-GNU-PR-Keywords: Original-Received: via spool by 10304-submit@debbugs.gnu.org id=B10304.132592615721389 (code B ref 10304); Sat, 07 Jan 2012 08:50:02 +0000 Original-Received: (at 10304) by debbugs.gnu.org; 7 Jan 2012 08:49:17 +0000 Original-Received: from localhost ([127.0.0.1]:47706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjRxi-0005Yq-Ci for submit@debbugs.gnu.org; Sat, 07 Jan 2012 03:49:17 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60463) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RjRxc-0005YZ-5Z for 10304@debbugs.gnu.org; Sat, 07 Jan 2012 03:49:12 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LXF0090070GDF00@a-mtaout20.012.net.il> for 10304@debbugs.gnu.org; Sat, 07 Jan 2012 10:48:33 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.156.26]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXF008FQ74WBZX0@a-mtaout20.012.net.il>; Sat, 07 Jan 2012 10:48:33 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:55491 Archived-At: > From: Lars Magne Ingebrigtsen > Cc: 10304@debbugs.gnu.org, Eli Zaretskii > Date: Sat, 07 Jan 2012 02:20:50 +0100 > > Yagnesh Raghava Yakkala writes: > > > I see this thing occasionally when reading news in group. I cant > > reproduce it at will. > > > > This screen shot is from article buffer, you can see the first line > > starts with "I tend to ... " is displayed twice in the screen (bottom > > also same line). In fact this messages was long, the line "I tend to > > ..." displayed at the bottom at the beginning. then I needed to hit SPC > > to read remaining part of the message. So the last line stays there > > Eli, if you look at the image included in this bug report, this looks > like the same display bug that I've seen a few times. It's as if Emacs > isn't clearing some parts of the screen when scrolling. (Sometimes.) > > I still haven't been able to make a test case for this. It happens to > me like a couple of times a week, so it's pretty obscure... Probably some redisplay optimization that doesn't exactly DTRT. When this happens, does it help to type "M-x redraw-display RET"? If it does, then, in the absence of a reproducible test case, all I can suggest is gather more info to narrow the range of possible offenders. Start by rebuilding Emacs with -DGLYPH_DEBUG=1, then start Emacs with stderr redirected to a file, toggle redisplay tracing with "M-x trace-redisplay RET", and wait till the problem happens. When it does, make the window with incorrect display the currently selected window, and type "M-x dump-glyph-matrix RET". Finally, send the contents of the redirected stderr here. There are also several variables that inhibit certain redisplay optimizations. They are defined in xdisp.c and are available only when Emacs is compiled with -DGLYPH_DEBUG=1: #if GLYPH_DEBUG DEFVAR_BOOL ("inhibit-try-window-id", inhibit_try_window_id, doc: /* Inhibit try_window_id display optimization. */); inhibit_try_window_id = 0; DEFVAR_BOOL ("inhibit-try-window-reusing", inhibit_try_window_reusing, doc: /* Inhibit try_window_reusing display optimization. */); inhibit_try_window_reusing = 0; DEFVAR_BOOL ("inhibit-try-cursor-movement", inhibit_try_cursor_movement, doc: /* Inhibit try_cursor_movement display optimization. */); inhibit_try_cursor_movement = 0; #endif /* GLYPH_DEBUG */ By selectively turning off each of these optimizations, we could zero in on the optimization that causes this bug. However, using these variables effectively needs some initial ideas about the possible causes, so I think gathering the info as suggested above is best as the first step.