GNU bug report logs - #17173
24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Wed, 2 Apr 2014 15:15:02 UTC

Severity: normal

Tags: moreinfo

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17173 in the body.
You can then email your comments to 17173 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 15:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 02 Apr 2014 15:15:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does
 not fix it
Date: Wed, 2 Apr 2014 08:14:16 -0700 (PDT)
Close this bug if you feel like it.  This is only to say that since a
few months ago (?) Emacs redisplay seems to be broken.  I do not have a
recipe, but I would be surprised if no one else sees this at all.

If I create a new frame (e.g. C-x 5 f) that partially obscures an
existing frame, for instance, and the select that partially obscured
frame (e.g., by clicking its title bar), so that it is raised again, the
part of the buffer that was obscured looks wiped out (blank).  And
repeated C-l does not fix this.  My workaround is to thumbify and then
dethumbify the frame.  (Probably iconifying and deiconifying would work
too, but I do not iconify anymore.)

This does not happen systematically - just sometimes.

Again, feel free to close this for its lack of reproducible recipe.
Just wanted to give you a heads-up that redisplay is somewhat broken
now.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-27 on ODIEONE
Bzr revision: 116884 lekktu <at> gmail.com-20140327173422-cr942b3hn7xjurks
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 15:50:02 GMT) Full text and rfc822 format available.

Message #8 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Drew Adams <drew.adams <at> oracle.com>, 17173 <at> debbugs.gnu.org
Subject: Re: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 02 Apr 2014 08:49:55 -0700
[Message part 1 (text/plain, inline)]
On 04/02/2014 08:14 AM, Drew Adams wrote:
> Close this bug if you feel like it.  This is only to say that since a
> few months ago (?) Emacs redisplay seems to be broken.  I do not have a
> recipe, but I would be surprised if no one else sees this at all.
> 
> If I create a new frame (e.g. C-x 5 f) that partially obscures an
> existing frame, for instance, and the select that partially obscured
> frame (e.g., by clicking its title bar), so that it is raised again, the
> part of the buffer that was obscured looks wiped out (blank).  And
> repeated C-l does not fix this.  My workaround is to thumbify and then
> dethumbify the frame.  (Probably iconifying and deiconifying would work
> too, but I do not iconify anymore.)
> 

I've never seen this behavior and can't repro it now. What window
manager are you using, and with what Emacs GUI toolkit?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 15:56:02 GMT) Full text and rfc822 format available.

Message #11 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 17173 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 2 Apr 2014 17:54:20 +0200
On Wed, Apr 2, 2014 at 5:49 PM, Daniel Colascione <dancol <at> dancol.org> wrote:

> I've never seen this behavior and can't repro it now. What window
> manager are you using, and with what Emacs GUI toolkit?

> Windowing system distributor `Microsoft Corp.', version 6.1.7601




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 15:59:02 GMT) Full text and rfc822 format available.

Message #14 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 17173 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 02 Apr 2014 08:58:07 -0700
[Message part 1 (text/plain, inline)]
On 04/02/2014 08:54 AM, Juanma Barranquero wrote:
> On Wed, Apr 2, 2014 at 5:49 PM, Daniel Colascione <dancol <at> dancol.org> wrote:
> 
>> I've never seen this behavior and can't repro it now. What window
>> manager are you using, and with what Emacs GUI toolkit?
> 
>> Windowing system distributor `Microsoft Corp.', version 6.1.7601

Er, yes, of course. This is going to be a good day, I can tell already.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 16:23:01 GMT) Full text and rfc822 format available.

Message #17 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Colascione <dancol <at> dancol.org>, 17173 <at> debbugs.gnu.org
Subject: RE: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 2 Apr 2014 09:21:54 -0700 (PDT)
> I've never seen this behavior and can't repro it now. What window
> manager are you using, and with what Emacs GUI toolkit?

MS Windows.  (The bug report specifies the build.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 16:24:02 GMT) Full text and rfc822 format available.

Message #20 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Colascione <dancol <at> dancol.org>, Juanma Barranquero
 <lekktu <at> gmail.com>
Cc: 17173 <at> debbugs.gnu.org
Subject: RE: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 2 Apr 2014 09:22:55 -0700 (PDT)
> Er, yes, of course. This is going to be a good day, I can tell already.

Don't jump to conclusions.  It just might be a good day after all. ;-)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 17:00:05 GMT) Full text and rfc822 format available.

Message #23 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17173 <at> debbugs.gnu.org
Subject: Re: bug#17173: 24.4.50;
 Emacs partially loses display, and redisplay via `C-l' does not fix it
Date: Wed, 02 Apr 2014 19:59:27 +0300
> Date: Wed, 2 Apr 2014 08:14:16 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> If I create a new frame (e.g. C-x 5 f) that partially obscures an
> existing frame, for instance, and the select that partially obscured
> frame (e.g., by clicking its title bar), so that it is raised again, the
> part of the buffer that was obscured looks wiped out (blank).  And
> repeated C-l does not fix this.

What about "M-x redraw-display RET" -- does it redisplay the frame in
its entirety?

> This does not happen systematically - just sometimes.

Can you try to figure out what distinguishes the cases when it happens
from those when it doesn't?  Maybe some mouse gesture before the click
on the obscured frame?  Or maybe it depends on which optional display
features (like display-time) you have enabled at the time?

Any idea when this started?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Wed, 02 Apr 2014 17:20:02 GMT) Full text and rfc822 format available.

Message #26 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17173 <at> debbugs.gnu.org
Subject: RE: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Wed, 2 Apr 2014 10:19:20 -0700 (PDT)
> What about "M-x redraw-display RET" -- does it redisplay the frame in
> its entirety?

Dunno.  I'll try that next time, I guess.

> > This does not happen systematically - just sometimes.
> 
> Can you try to figure out what distinguishes the cases when it happens
> from those when it doesn't?  Maybe some mouse gesture before the click
> on the obscured frame?  Or maybe it depends on which optional display
> features (like display-time) you have enabled at the time?

I will try to pay attention.  I don't think that my actions in Emacs
beforehand are necessarily related - I have seen this happen also when
returning to an Emacs frame after using another Windows app (window mgr
window).

I don't change things like display-time (I show it, normally), but I do
sometimes show other info in the mode line temporarily (returning to my
usual mode line, with display-time).  My usual `mode-line-format', FWIW:

("%e"
 #("-" 0 1
   (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this"))
 mode-line-mule-info mode-line-client mode-line-modified mode-line-remote
 mode-line-frame-identification mode-line-buffer-identification
 #("   " 0 3
   (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this"))
 mode-line-position
 (vc-mode vc-mode)
 #("  " 0 2
   (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this"))
 mode-line-modes
 (which-func-mode
  ("" which-func-format
   #("--" 0 2
     (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this"))))
 (global-mode-string
  (#("--" 0 2
     (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this"))
   global-mode-string))
 #("-%-" 0 3
   (help-echo "mouse-1: Select (drag to resize), mouse-2: Delete others, \
mouse-3: Delete this")))

> Any idea when this started?

Sorry, not really.  I think it started around the same time as other
redisplay problems that I and others have reported lately - late last year,
perhaps?  Dunno.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Sat, 26 Dec 2015 14:11:01 GMT) Full text and rfc822 format available.

Message #29 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17173 <at> debbugs.gnu.org
Subject: Re: bug#17173: 24.4.50;
 Emacs partially loses display, and redisplay via `C-l' does not fix it
Date: Sat, 26 Dec 2015 15:09:49 +0100
Drew Adams <drew.adams <at> oracle.com> writes:

>> Can you try to figure out what distinguishes the cases when it happens
>> from those when it doesn't?  Maybe some mouse gesture before the click
>> on the obscured frame?  Or maybe it depends on which optional display
>> features (like display-time) you have enabled at the time?
>
> I will try to pay attention.  I don't think that my actions in Emacs
> beforehand are necessarily related - I have seen this happen also when
> returning to an Emacs frame after using another Windows app (window mgr
> window).

Are you still seeing this problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Sat, 26 Dec 2015 16:39:01 GMT) Full text and rfc822 format available.

Message #32 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17173 <at> debbugs.gnu.org
Subject: RE: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Sat, 26 Dec 2015 08:38:47 -0800 (PST)
> Are you still seeing this problem?

Yes, sometimes.  My impression is that Emacs 25 does redisplay
less often or something, and so there are occasions where the
display is messed up.  And yes, C-l sometimes has no effect
to clear it up.  To clear it up, I minimize the frame and then
restore it, or sometimes it helps to just resize the frame.

I cannot tell you when the problem arises.  I can tell you
that the problem exists.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Sat, 26 Dec 2015 16:44:02 GMT) Full text and rfc822 format available.

Message #35 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 17173 <at> debbugs.gnu.org
Subject: Re: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Sat, 26 Dec 2015 18:43:59 +0200
> Date: Sat, 26 Dec 2015 08:38:47 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 17173 <at> debbugs.gnu.org
> 
> > Are you still seeing this problem?
> 
> Yes, sometimes.  My impression is that Emacs 25 does redisplay
> less often or something

We (mostly Stefan) made redisplay faster by removing some triggers
that would redraw windows unnecessarily.  Such optimizations always
leave some fallout that needs to be fixed.

> and so there are occasions where the display is messed up.  And yes,
> C-l sometimes has no effect to clear it up.  To clear it up, I
> minimize the frame and then restore it, or sometimes it helps to
> just resize the frame.
> 
> I cannot tell you when the problem arises.  I can tell you
> that the problem exists.

It is impossible to fix these problems without a reproducible recipe.
The only alternative is to wait for someone else to come up with a bug
report and a recipe, which will solve this problem as a side effect.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Sat, 26 Dec 2015 17:30:03 GMT) Full text and rfc822 format available.

Message #38 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 17173 <at> debbugs.gnu.org
Subject: RE: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Sat, 26 Dec 2015 09:29:16 -0800 (PST)
> We (mostly Stefan) made redisplay faster by removing some triggers
> that would redraw windows unnecessarily.  Such optimizations always
> leave some fallout that needs to be fixed.
> 
> It is impossible to fix these problems without a reproducible recipe.
> The only alternative is to wait for someone else to come up with a bug
> report and a recipe, which will solve this problem as a side effect.

I understand.  If there is no way to correlate the source changes
made with the bug report, and so lots of such source changes could
affect this, then the bug report cannot help.  Feel free to close
it in that case.  Hopefully another report will come along, with
more precise info.

Maybe, when such wholesale optimizations are made in the future,
some debug code can be added, so that symptoms such as I reported
can more easily be traced to particular source changes?  Is that
feasible?

My impression is that this is not the only bug report about
failures to redisplay properly in Emacs 25.  Seems like we have,
on the one hand, lots of redisplay optimizations implemented
together, or within a short timespan, and a fair number of
redisplay problems reported, and no specific, operational
connections made between the two.  If so, that's too bad.




bug closed, send any further explanations to 17173 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 26 Dec 2015 17:55:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17173; Package emacs. (Sat, 26 Dec 2015 18:20:02 GMT) Full text and rfc822 format available.

Message #43 received at 17173 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, 17173 <at> debbugs.gnu.org
Subject: Re: bug#17173: 24.4.50; Emacs partially loses display, and redisplay
 via `C-l' does not fix it
Date: Sat, 26 Dec 2015 20:20:12 +0200
> Date: Sat, 26 Dec 2015 09:29:16 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: larsi <at> gnus.org, 17173 <at> debbugs.gnu.org
> 
> Maybe, when such wholesale optimizations are made in the future,
> some debug code can be added, so that symptoms such as I reported
> can more easily be traced to particular source changes?  Is that
> feasible?

We have the debug code.  I myself use it all the time, and several
times asked people who reported bugs to enable it and show the output.
But it produces a lot of output, so it is only feasible to turn it on
when running a reproducible recipe.  Which we don't have in this case.

> My impression is that this is not the only bug report about
> failures to redisplay properly in Emacs 25.  Seems like we have,
> on the one hand, lots of redisplay optimizations implemented
> together, or within a short timespan, and a fair number of
> redisplay problems reported, and no specific, operational
> connections made between the two.

There were indeed several reports about redisplay problems, related to
those changes.  They were all fixed, AFAICT, because each one
eventually succeeded to find a recipe for reproducing the problem.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 24 Jan 2016 12:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 154 days ago.

Previous Next


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