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

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

[Drew Adams]

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@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''

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Juanma Barranquero]

On Wed, Apr 2, 2014 at 5:49 PM, Daniel Colascione <dancol@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

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On 04/02/2014 08:54 AM, Juanma Barranquero wrote:
> On Wed, Apr 2, 2014 at 5:49 PM, Daniel Colascione <dancol@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Drew Adams]

> 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. ;-)

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

[Drew Adams]

> 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.)

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

[Eli Zaretskii]

> Date: Wed, 2 Apr 2014 08:14:16 -0700 (PDT)
> From: Drew Adams <drew.adams@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?

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

[Drew Adams]

> 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.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

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

[Drew Adams]

> 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.

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

[Eli Zaretskii]

> Date: Sat, 26 Dec 2015 08:38:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 17173@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.

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

[Drew Adams]

> 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#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it

[Eli Zaretskii]

> Date: Sat, 26 Dec 2015 09:29:16 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: larsi@gnus.org, 17173@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.