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

unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
       [not found] ` <<83lhvnbrbk.fsf@gnu.org>
@ 2014-04-02 17:19   ` Drew Adams
  2015-12-26 14:09     ` Lars Ingebrigtsen
       [not found]   ` <<849e9e65-3cc7-45b9-b388-da5993600278@default>
  1 sibling, 1 reply; 13+ messages in thread
From: Drew Adams @ 2014-04-02 17:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 17:19   ` bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it Drew Adams
@ 2015-12-26 14:09     ` Lars Ingebrigtsen
  2015-12-26 16:38       ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-26 14:09 UTC (permalink / raw)
  To: Drew Adams; +Cc: 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2015-12-26 14:09     ` Lars Ingebrigtsen
@ 2015-12-26 16:38       ` Drew Adams
  2015-12-26 16:43         ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2015-12-26 16:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 17173

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2015-12-26 16:38       ` Drew Adams
@ 2015-12-26 16:43         ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2015-12-26 16:43 UTC (permalink / raw)
  To: Drew Adams; +Cc: larsi, 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

[parent not found: <<849e9e65-3cc7-45b9-b388-da5993600278@default>]

[parent not found: <<87si2pz4gi.fsf@gnus.org>]

[parent not found: <<5a3eb48a-6574-41bc-a8c2-37659ec5ebde@default>]

[parent not found: <<83a8oxi2i8.fsf@gnu.org>]

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
       [not found]         ` <<83a8oxi2i8.fsf@gnu.org>
@ 2015-12-26 17:29           ` Drew Adams
  2015-12-26 18:20             ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2015-12-26 17:29 UTC (permalink / raw)
  To: Eli Zaretskii, Drew Adams; +Cc: larsi, 17173

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2015-12-26 17:29           ` Drew Adams
@ 2015-12-26 18:20             ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2015-12-26 18:20 UTC (permalink / raw)
  To: Drew Adams; +Cc: larsi, 17173

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
@ 2014-04-02 15:14 Drew Adams
  2014-04-02 15:49 ` Daniel Colascione
  2014-04-02 16:59 ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Drew Adams @ 2014-04-02 15:14 UTC (permalink / raw)
  To: 17173

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:14 Drew Adams
@ 2014-04-02 15:49 ` Daniel Colascione
  2014-04-02 15:54   ` Juanma Barranquero
  2014-04-02 16:21   ` Drew Adams
  2014-04-02 16:59 ` Eli Zaretskii
  1 sibling, 2 replies; 13+ messages in thread
From: Daniel Colascione @ 2014-04-02 15:49 UTC (permalink / raw)
  To: Drew Adams, 17173

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:49 ` Daniel Colascione
@ 2014-04-02 15:54   ` Juanma Barranquero
  2014-04-02 15:58     ` Daniel Colascione
  2014-04-02 16:21   ` Drew Adams
  1 sibling, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2014-04-02 15:54 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:54   ` Juanma Barranquero
@ 2014-04-02 15:58     ` Daniel Colascione
  2014-04-02 16:22       ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Colascione @ 2014-04-02 15:58 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 17173

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:58     ` Daniel Colascione
@ 2014-04-02 16:22       ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2014-04-02 16:22 UTC (permalink / raw)
  To: Daniel Colascione, Juanma Barranquero; +Cc: 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:49 ` Daniel Colascione
  2014-04-02 15:54   ` Juanma Barranquero
@ 2014-04-02 16:21   ` Drew Adams
  1 sibling, 0 replies; 13+ messages in thread
From: Drew Adams @ 2014-04-02 16:21 UTC (permalink / raw)
  To: Daniel Colascione, 17173

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it
  2014-04-02 15:14 Drew Adams
  2014-04-02 15:49 ` Daniel Colascione
@ 2014-04-02 16:59 ` Eli Zaretskii
  1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2014-04-02 16:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 17173

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2015-12-26 18:20 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <<17026dc9-ee25-4e83-a5c4-86140d37e250@default>
     [not found] ` <<83lhvnbrbk.fsf@gnu.org>
2014-04-02 17:19   ` bug#17173: 24.4.50; Emacs partially loses display, and redisplay via `C-l' does not fix it Drew Adams
2015-12-26 14:09     ` Lars Ingebrigtsen
2015-12-26 16:38       ` Drew Adams
2015-12-26 16:43         ` Eli Zaretskii
     [not found]   ` <<849e9e65-3cc7-45b9-b388-da5993600278@default>
     [not found]     ` <<87si2pz4gi.fsf@gnus.org>
     [not found]       ` <<5a3eb48a-6574-41bc-a8c2-37659ec5ebde@default>
     [not found]         ` <<83a8oxi2i8.fsf@gnu.org>
2015-12-26 17:29           ` Drew Adams
2015-12-26 18:20             ` Eli Zaretskii
2014-04-02 15:14 Drew Adams
2014-04-02 15:49 ` Daniel Colascione
2014-04-02 15:54   ` Juanma Barranquero
2014-04-02 15:58     ` Daniel Colascione
2014-04-02 16:22       ` Drew Adams
2014-04-02 16:21   ` Drew Adams
2014-04-02 16:59 ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).