GNU bug report logs -
#17173
24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
Previous Next
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.
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):
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):
[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):
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):
[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):
> 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):
> 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):
> 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):
> 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):
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):
> 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):
> 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):
> 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):
> 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.