bug#10304: 24.0.92: display but

[Yagnesh Raghava Yakkala]

Yagnesh Raghava Yakkala <yag...@live.com> writes:


Typo
I meant "display bug"

> 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
>
> I hope my description is clear.

--
YYR

[Lars Magne Ingebrigtsen]

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

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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>
> Cc: 10...@debbugs.gnu.org, Eli Zaretskii <el...@gnu.org>
> Date: Sat, 07 Jan 2012 02:20:50 +0100

>
> Yagnesh Raghava Yakkala <yag...@live.com> 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.

[Lars Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> When this happens, does it help to type "M-x redraw-display RET"?

Yes, it does.

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

Thanks for the recipe; I'll do this the next time I see this redisplay
glitch.

--
(domestic pets only, the antidote for overdose, milk.)

http://lars.ingebrigtsen.no * Sent from my Rome

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Date: Wed, 02 Jan 2013 03:36:28 +0100
>
> Unfortunately, I hadn't compiled Emac with -DGLYPH_DEBUG=1 (but am going
> to do it now), but at least I managed to take some screen shots now,
> which may give somebody an idea about what the problem is, perhaps.

Is this reproducible, e.g., with that blog post? I've seen in the
past redisplay problem with images, but they would disappear in a
fresh session of Emacs, even if I made exactly the same gestures as
the ones which reproduce the problem in a long-running session. Do
you have the same experience?

When you do have Emacs built with -DGLYPH_DEBUG=1, and this happens,
invoke "M-x trace-redisplay RET", and tell what it prints to stderr
when you do whatever is needed to reproduce the problem.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> Is this reproducible, e.g., with that blog post?

Nope. After refreshing the display once, it doesn't happen again.

I'd say that it happens about, er, once a thousand times that Emacs
displays a message, and it's totally unreproducible.

I *think* what happens is always that this only happens when I scroll
the buffer down and it reaches the end. After the end of the buffer,
the bottom of the window should be totally blanked out, but sometimes
(if there's an image in the part that should have been blanked out after
scrolling), it doesn't happen.

So my feeling is that there may perhaps be an optimisation relating to
clearing the window after end-of-buffer. But that may be totally wrong,
of course. :-)

> I've seen in the past redisplay problem with images, but they would
> disappear in a fresh session of Emacs, even if I made exactly the same
> gestures as the ones which reproduce the problem in a long-running
> session. Do you have the same experience?

Yes.

> When you do have Emacs built with -DGLYPH_DEBUG=1, and this happens,
> invoke "M-x trace-redisplay RET", and tell what it prints to stderr
> when you do whatever is needed to reproduce the problem.

I'm now running with GLYPH_DEBUG and STDERR to a file, so I should be
able to get a trace the next time...

--
(domestic pets only, the antidote for overdose, milk.)

bloggy blog http://lars.ingebrigtsen.no/

[Andreas Schwab]

Lars Magne Ingebrigtsen <la...@gnus.org> writes:

> I *think* what happens is always that this only happens when I scroll
> the buffer down and it reaches the end. After the end of the buffer,
> the bottom of the window should be totally blanked out, but sometimes
> (if there's an image in the part that should have been blanked out after
> scrolling), it doesn't happen.

I've also seen it happen in the middle of a buffer, ie. the image is
half overwritten by the new text, but the blank area after eol is not
cleared.

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Lars Magne Ingebrigtsen]

Ok, I got a display bug, and it was of the same time as before: After
scrolling, area after the end of the buffer wasn't cleared, leaving the
image.

I switched on trace-redisplay, paged back and forth, which was still
buggy, and then did a matrix dump.

Then the window fixed itself suddenly without me doing anything.

Here's the output from the log file.

redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): forced window start
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): forced window start
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_internal 0
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1
0x35c3880 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1
0x35c3880 ( *Minibuf-1*): optimization 1
PT = 171, BEGV = 1. ZV = 176
Cursor x = 0, y = 20, hpos = 0, vpos = 1
=============================================
0: (1) ''
0: (1) ' '
0: (1) ''
1: (1) ''
1: (1) 'Link '
1: (1) ''
2: (1) ''
2: (1) ' '
2: (1) ''
3: (1) ''
3: (1) ' '
3: (1) ''
4: (1) ''
4: (1) ' '
4: (1) ''
5: (1) ''
5: (1) ' '
5: (1) ''
6: (1) ''
6: (1) ' '
6: (1) ''
7: (1) ''
7: (1) ' '
7: (1) ''
8: (1) ''
8: (1) ' '
8: (1) ''
9: (1) ''
9: (1) ' '
9: (1) ''
10: (1) ''
10: (1) ' '
10: (1) ''
11: (1) ''
11: (1) ' '
11: (1) ''
12: (1) ''
12: (1) ' '
12: (1) ''
13: (1) ''
13: (1) ' '
13: (1) ''
14: (1) ''
14: (1) ' '
14: (1) ''
15: (1) ''
15: (1) ' '
15: (1) ''
16: (1) ''
16: (1) ' '
16: (1) ''
17: (1) ''
17: (1) ' '
17: (1) ''
18: (1) ''
18: (1) ' '
18: (1) ''
19: (1) ''
19: (1) ' '
19: (1) ''
20: (1) ''
20: (1) ' '
20: (1) ''
21: (1) ''
21: (1) ' '
21: (1) ''
22: (1) ''
22: (1) ' '
22: (1) ''
23: (1) ''
23: (1) ' '
23: (1) ''
24: (1) ''
24: (1) ' '
24: (1) ''
25: (1) ''
25: (1) ' '
25: (1) ''
26: (1) ''
26: (1) ' '
26: (1) ''
27: (1) ''
27: (1) ' '
27: (1) ''
28: (1) ''
28: (1) ' '
28: (1) ''
29: (1) ''
29: (1) ' '
29: (1) ''
30: (1) ''
30: (1) ' '
30: (1) ''
31: (1) ''
31: (1) ' '
31: (1) ''
32: (1) ''
32: (1) ' '
32: (1) ''
33: (1) ''
33: (1) ' '
33: (1) ''
34: (1) ''
34: (1) ' '
34: (1) ''
35: (1) ''
35: (1) ' '
35: (1) ''
36: (1) ''
36: (1) ' '
36: (1) ''
37: (1) ''
37: (1) ' '
37: (1) ''
38: (1) ''
38: (1) ' '
38: (1) ''
39: (1) ''
39: (1) ' '
39: (1) ''
40: (1) ''
40: (1) ' '
40: (1) ''
41: (1) ''
41: (1) ' '
41: (1) ''
42: (1) ''
42: (1) ' '
42: (1) ''
43: (0) ''
43: (0) ''
43: (0) ''
44: (0) ''
44: (0) ''
44: (0) ''
45: (0) ''
45: (0) ''
45: (0) ''
46: (0) ''
46: (0) ''
46: (0) ''
47: (0) ''
47: (0) ''
47: (0) ''
48: (0) ''
48: (0) ''
48: (0) ''
49: (0) ''
49: (0) ''
49: (0) ''
50: (0) ''
50: (0) ''
50: (0) ''
51: (0) ''
51: (0) ''
51: (0) ''
52: (0) ''
52: (0) ''
52: (0) ''
53: (0) ''
53: (0) ''
53: (0) ''
54: (0) ''
54: (0) ''
54: (0) ''
55: (0) ''
55: (0) ''
55: (0) ''
56: (0) ''
56: (0) ''
56: (0) ''
57: (0) ''
57: (0) ''
57: (0) ''
58: (0) ''
58: (0) ''
58: (0) ''
59: (0) ''
59: (0) ''
59: (0) ''
60: (0) ''
60: (0) ''
60: (0) ''
61: (0) ''
61: (0) ''
61: (0) ''
62: (0) ''
62: (0) ''
62: (0) ''
63: (0) ''
63: (0) ''
63: (0) ''
64: (0) ''
64: (0) ''
64: (0) ''
65: (0) ''
65: (0) ''
65: (0) ''
66: (0) ''
66: (0) ''
66: (0) ''
67: (0) ''
67: (0) ''
67: (0) ''
68: (0) ''
68: (0) ''
68: (0) ''
69: (0) ''
69: (0) ''
69: (0) ''
70: (1) ''
70: (1) ' 1:--- . news:g.o.j.blog More Tea, You Monster? (1... Bot L8 (Article) '
70: (1) ''
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (13)
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_preserve_echo_area (13)
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_preserve_echo_area (13)
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
expose_frame (796, 696, 24, 484)
expose_window (796, 696, 24, 464)
expose_window (796, 1160, 24, 20)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): forced window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): forced window start
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x372ff70 (*Summary nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): same window start
0x5343aa8 (*Article nntp+news.gmane.org:gwene.org.jwz.blog*): 1
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
0x5168d70 (sendmail.el): same window start
0x5168d70 (sendmail.el): 1
0x4bc23a0 (smtpmail.el): same window start
0x4bc23a0 (smtpmail.el): 1
redisplay_internal 0
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1
0x35c3880 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x35c3880 ( *Minibuf-1*): same window start
0x35c3880 ( *Minibuf-1*): 1
redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1
0x35c3880 ( *Minibuf-1*): optimization 1

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Date: Sat, 05 Jan 2013 09:38:00 +0100

>
> Ok, I got a display bug, and it was of the same time as before: After
> scrolling, area after the end of the buffer wasn't cleared, leaving the
> image.
>
> I switched on trace-redisplay, paged back and forth, which was still
> buggy, and then did a matrix dump.

Thanks.

> Then the window fixed itself suddenly without me doing anything.

Does the trace you posted include the time when the window
fixed itself, and if so, can you try identifying in the trace the
place where it happened? Could it be here:

expose_frame (796, 696, 24, 484)
expose_window (796, 696, 24, 464)
expose_window (796, 1160, 24, 20)

> Here's the output from the log file.

I will study it, but it is important for me to understand how this log
is related to whatever you did in Emacs. Does this reflect only the
"page back and forth, and the matrix dump", or does it include more
stuff?

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

>> Then the window fixed itself suddenly without me doing anything.
>
> Does the trace you posted include the time when the window
> fixed itself, and if so, can you try identifying in the trace the
> place where it happened? Could it be here:
>
> expose_frame (796, 696, 24, 484)
> expose_window (796, 696, 24, 464)
> expose_window (796, 1160, 24, 20)

I had switched to an xterm that was partially overshadowing the Emacs
frame, and typing away in that xterm. And then suddenly the Emacs frame
updated itself and everything was OK. So I'm not sure how that relates
to the blog, but it was after the glyph dump, at least.

>> Here's the output from the log file.
>
> I will study it, but it is important for me to understand how this log
> is related to whatever you did in Emacs. Does this reflect only the
> "page back and forth, and the matrix dump", or does it include more
> stuff?

What I did was read the message (from the *Summary* buffer), hit SPC,
and the *Article* buffer scrolled forwards and had the wrong display.

Then I jumped to and xterm to read the instructions I had saved in a
file there. Then I think I went back to the Emacs frame, typed `M-x
trace-redisplay', scrolled back and forth (with the bug still
displaying), then did a dump-glyph-matrix, then went back to the xterm,
and then Emacs spontaneously fixed itself, and then I went back to the
Emacs frame and switched the trace off.

I think. :-)

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> Does the trace you posted include the time when the window
> fixed itself, and if so, can you try identifying in the trace the
> place where it happened? Could it be here:
>
> expose_frame (796, 696, 24, 484)
> expose_window (796, 696, 24, 464)
> expose_window (796, 1160, 24, 20)

By the way, perhaps the trace log should have timestamping on the lines
to be able to match it up more easily to user actions?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Cc: 10...@debbugs.gnu.org
> Date: Sat, 05 Jan 2013 10:17:51 +0100

>
> By the way, perhaps the trace log should have timestamping on the lines
> to be able to match it up more easily to user actions?

What would you compare those time stamps with, to find out what trace
corresponds to which user action?

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

>> By the way, perhaps the trace log should have timestamping on the lines
>> to be able to match it up more easily to user actions?
>
> What would you compare those time stamps with, to find out what trace
> corresponds to which user action?

In this case, the pause in actions would presumably correspond to me
typing away in the xterm, for instance.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Date: Sat, 05 Jan 2013 09:38:00 +0100

According to this, the window had 70 lines, of which 43 displayed
text; that text was comprised of empty lines, except for the 2nd line
which displayed the text "Link "; and point was on that 2nd line.
Does that sound reasonable?

Btw, next time please use (dump-glyph-matrix 2), to get more
information about the glyphs on display.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> According to this, the window had 70 lines, of which 43 displayed
> text; that text was comprised of empty lines, except for the 2nd line
> which displayed the text "Link "; and point was on that 2nd line.
> Does that sound reasonable?

Yes, the only text in the buffer was the Link thing, and that was
probably on the second line. However, the window was (let's see) 43
lines tall.

The image was (faultily) displayed right below the Link.

> Btw, next time please use (dump-glyph-matrix 2), to get more
> information about the glyphs on display.

Will do.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Cc: 10...@debbugs.gnu.org
> Date: Sat, 05 Jan 2013 12:38:07 +0100

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > According to this, the window had 70 lines, of which 43 displayed
> > text; that text was comprised of empty lines, except for the 2nd line
> > which displayed the text "Link "; and point was on that 2nd line.
> > Does that sound reasonable?
>
> Yes, the only text in the buffer was the Link thing, and that was
> probably on the second line. However, the window was (let's see) 43
> lines tall.

OK, that's my misreading of the dump: the "(0)" part means the line is
disabled in the glyph matrix, i.e. not displayed.

> The image was (faultily) displayed right below the Link.

So the bug seems to be that we don't clear those empty lines which
occupied the screen estate of the image. Hmm...

> > Btw, next time please use (dump-glyph-matrix 2), to get more
> > information about the glyphs on display.
>
> Will do.

Also, I just installed a few changes on the emacs-24 branch that make
the matrix dump better, please resync if you can.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>
> Cc: 10...@debbugs.gnu.org
> Date: Sat, 05 Jan 2013 12:38:07 +0100
>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > According to this, the window had 70 lines, of which 43 displayed
> > text; that text was comprised of empty lines, except for the 2nd line
> > which displayed the text "Link "; and point was on that 2nd line.
> > Does that sound reasonable?
>
> Yes, the only text in the buffer was the Link thing, and that was
> probably on the second line. However, the window was (let's see) 43
> lines tall.
>

> The image was (faultily) displayed right below the Link.

Could you describe in more detail what happened to cause the text at
the end of the buffer be displayed instead of the image? Is it that
the buffer included an image and also some text, and that buffer was
scrolled such that the image went out of view and the text came into
view? Or was it some other scenario, like maybe switching buffers in
the window?

Andreas, perhaps you also could give such details about your case?

I think I see the code that could be the culprit, but I need to
understand better how the new display replaced the old one, to dig
deeper.

TIA

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> Could you describe in more detail what happened to cause the text at
> the end of the buffer be displayed instead of the image? Is it that
> the buffer included an image and also some text, and that buffer was
> scrolled such that the image went out of view and the text came into
> view? Or was it some other scenario, like maybe switching buffers in
> the window?

I had a beautiful example of the bug last night, but I fumbled and make
the window go away before I could get a screen shot.

And the redisplay log was truncated because I had started two Emacsen
pointing to the same file. *sigh*

Anyway, here's the bits I could salvage from the log, and a glyph dump.

To explain what happens is that I have a window that has an image in
it. When I then scroll the buffer forwards, so that the window displays
the end-of-buffer, and the image occupied (visually) part of the window
after the end-of-buffer, then the rest of the window isn't blanked.

Ok, that explanation didn't make much sense.

I'll try to draw.

Here's what the window looks like first, when everything is OK:

-----------------------------
| bla bla bla |
| bla bla bla |
| |
| -------- |
| |** ***| |
| |*image| |
| |** ***| |
| |** ***| |
| -------- |
| |
| bla bla |
| bla bla |
-----------------------------

Then I scroll.

-----------------------------
| foo |
| zot |
| more foo |
| this is the end of the |
| buffer |
| |
| |** ***| |
| |** ***| |
| -------- |
| |
| bla bla |
| bla bla |
-----------------------------

And the buffer ends where it says. :-)

So I get the bottom half of the image, and then whatever was after the
image.

So it's like it decides that it doesn't have to blank the window after
end-of-buffer if end-of-buffer happens in the middle of the image that
was displayed there. If you understand what I mean. :-)


redisplay_internal 0
0x5da9f78 (article): same window start
0x5da9f78 (article): 1
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0

0x5da9f78 (article): same window start
0x5da9f78 (article): 1
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_preserve_echo_area (2)
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
trying display optimization 1
0x10e8590 ( *Minibuf-1*): optimization 1
redisplay_internal 0
trying display optimization 1
0x10e8590 ( *Minibuf-1*): optimization 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1
PT = 204, BEGV = 1. ZV = 319
Cursor x = 0, y = 80, hpos = 0, vpos = 4
=============================================
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
0 1 32 31 010000100000 0 0 310 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 1 B 10 0x000046 F 14 00
1 C 2 B 10 0x000072 r 14 00
2 C 3 B 10 0x00006f o 14 00
3 C 4 B 10 0x00006d m 14 00
4 C 5 B 10 0x00003a : 14 00
5 C 6 B 10 0x000020 15 00
6 C 7 B 10 0x000075 u 16 00
7 C 8 B 10 0x00006e n 16 00
8 C 9 B 10 0x00006b k 16 00
9 C 10 B 10 0x00006e n 16 00
10 C 11 B 10 0x00006f o 16 00
11 C 12 B 10 0x000077 w 16 00
12 C 13 B 10 0x00006e n 16 00
13 C 14 B 10 0x000020 16 00
14 C 15 B 10 0x00003c < 16 00
15 C 16 B 10 0x000070 p 16 00
16 C 17 B 10 0x00006f o 16 00
17 C 18 B 10 0x000073 s 16 00
18 C 19 B 10 0x000074 t 16 00
19 C 20 B 10 0x000040 @ 16 00
20 C 21 B 10 0x000067 g 16 00
21 C 22 B 10 0x000077 w 16 00
22 C 23 B 10 0x000065 e 16 00
23 C 24 B 10 0x00006e n 16 00
24 C 25 B 10 0x000065 e 16 00
25 C 26 B 10 0x00002e . 16 00
26 C 27 B 10 0x00006f o 16 00
27 C 28 B 10 0x000072 r 16 00
28 C 29 B 10 0x000067 g 16 00
29 C 30 B 10 0x00003e > 16 00
30 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
1 32 84 52 010000100000 0 20 520 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 32 B 10 0x000053 S 14 00
1 C 33 B 10 0x000075 u 14 00
2 C 34 B 10 0x000062 b 14 00
3 C 35 B 10 0x00006a j 14 00
4 C 36 B 10 0x000065 e 14 00
5 C 37 B 10 0x000063 c 14 00
6 C 38 B 10 0x000074 t 14 00
7 C 39 B 10 0x00003a : 14 00
8 C 40 B 10 0x000020 17 00
9 C 41 B 10 0x000042 B 17 00
10 C 42 B 10 0x000061 a 17 00
11 C 43 B 10 0x000074 t 17 00
12 C 44 B 10 0x000068 h 17 00
13 C 45 B 10 0x000020 17 00
14 C 46 B 10 0x000054 T 17 00
15 C 47 B 10 0x000069 i 17 00
16 C 48 B 10 0x00006d m 17 00
17 C 49 B 10 0x000065 e 17 00
18 C 50 B 10 0x000020 17 00
19 C 51 B 10 0x000066 f 17 00
20 C 52 B 10 0x00006f o 17 00
21 C 53 B 10 0x000072 r 17 00
22 C 54 B 10 0x000020 17 00
23 C 55 B 10 0x00004d M 17 00
24 C 56 B 10 0x00006f o 17 00
25 C 57 B 10 0x000077 w 17 00
26 C 58 B 10 0x000067 g 17 00
27 C 59 B 10 0x00006c l 17 00
28 C 60 B 10 0x000069 i 17 00
29 C 61 B 10 0x00003a : 17 00
30 C 62 B 10 0x000020 17 00
31 C 63 B 10 0x000042 B 17 00
32 C 64 B 10 0x000065 e 17 00
33 C 65 B 10 0x00006e n 17 00
34 C 66 B 10 0x000067 g 17 00
35 C 67 B 10 0x000061 a 17 00
36 C 68 B 10 0x00006c l 17 00
37 C 69 B 10 0x000020 17 00
38 C 70 B 10 0x000043 C 17 00
39 C 71 B 10 0x000061 a 17 00
40 C 72 B 10 0x000074 t 17 00
41 C 73 B 10 0x000020 17 00
42 C 74 B 10 0x000069 i 17 00
43 C 75 B 10 0x00006e n 17 00
44 C 76 B 10 0x000020 17 00
45 C 77 B 10 0x000061 a 17 00
46 C 78 B 10 0x000020 17 00
47 C 79 B 10 0x000053 S 17 00
48 C 80 B 10 0x000069 i 17 00
49 C 81 B 10 0x00006e n 17 00
50 C 82 B 10 0x00006b k 17 00
51 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
2 84 129 45 010000100000 0 40 450 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 84 B 10 0x00004e N 14 00
1 C 85 B 10 0x000065 e 14 00
2 C 86 B 10 0x000077 w 14 00
3 C 87 B 10 0x000073 s 14 00
4 C 88 B 10 0x000067 g 14 00
5 C 89 B 10 0x000072 r 14 00
6 C 90 B 10 0x00006f o 14 00
7 C 91 B 10 0x000075 u 14 00
8 C 92 B 10 0x000070 p 14 00
9 C 93 B 10 0x000073 s 14 00
10 C 94 B 10 0x00003a : 14 00
11 C 95 B 10 0x000020 18 00
12 C 96 B 10 0x000067 g 18 00
13 C 97 B 10 0x000077 w 18 00
14 C 98 B 10 0x000065 e 18 00
15 C 99 B 10 0x00006e n 18 00
16 C 100 B 10 0x000065 e 18 00
17 C 101 B 10 0x00002e . 18 00
18 C 102 B 10 0x000063 c 18 00
19 C 103 B 10 0x00006f o 18 00
20 C 104 B 10 0x00006d m 18 00
21 C 105 B 10 0x00002e . 18 00
22 C 106 B 10 0x000066 f 18 00
23 C 107 B 10 0x000065 e 18 00
24 C 108 B 10 0x000065 e 18 00
25 C 109 B 10 0x000064 d 18 00
26 C 110 B 10 0x000062 b 18 00
27 C 111 B 10 0x000075 u 18 00
28 C 112 B 10 0x000072 r 18 00
29 C 113 B 10 0x00006e n 18 00
30 C 114 B 10 0x000065 e 18 00
31 C 115 B 10 0x000072 r 18 00
32 C 116 B 10 0x00002e . 18 00
33 C 117 B 10 0x000063 c 18 00
34 C 118 B 10 0x000068 h 18 00
35 C 119 B 10 0x000065 e 18 00
36 C 120 B 10 0x000065 e 18 00
37 C 121 B 10 0x00007a z 18 00
38 C 122 B 10 0x000062 b 18 00
39 C 123 B 10 0x000075 u 18 00
40 C 124 B 10 0x000072 r 18 00
41 C 125 B 10 0x000067 g 18 00
42 C 126 B 10 0x000065 e 18 00
43 C 127 B 10 0x000072 r 18 00
44 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
3 129 204 75 010000100000 0 60 750 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 129 B 10 0x000044 D 14 00
1 C 130 B 10 0x000061 a 14 00
2 C 131 B 10 0x000074 t 14 00
3 C 132 B 10 0x000065 e 14 00
4 C 133 B 10 0x00003a : 14 00
5 C 134 B 10 0x000020 18 00
6 C 135 B 10 0x00004d M 18 00
7 C 136 B 10 0x00006f o 18 00
8 C 137 B 10 0x00006e n 18 00
9 C 138 B 10 0x00002c , 18 00
10 C 139 B 10 0x000020 18 00
11 C 140 B 10 0x000030 0 18 00
12 C 141 B 10 0x000037 7 18 00
13 C 142 B 10 0x000020 18 00
14 C 143 B 10 0x00004a J 18 00
15 C 144 B 10 0x000061 a 18 00
16 C 145 B 10 0x00006e n 18 00
17 C 146 B 10 0x000020 18 00
18 C 147 B 10 0x000032 2 18 00
19 C 148 B 10 0x000030 0 18 00
20 C 149 B 10 0x000031 1 18 00
21 C 150 B 10 0x000033 3 18 00
22 C 151 B 10 0x000020 18 00
23 C 152 B 10 0x000031 1 18 00
24 C 153 B 10 0x000035 5 18 00
25 C 154 B 10 0x00003a : 18 00
26 C 155 B 10 0x000030 0 18 00
27 C 156 B 10 0x000030 0 18 00
28 C 157 B 10 0x00003a : 18 00
29 C 158 B 10 0x000030 0 18 00
30 C 159 B 10 0x000030 0 18 00
31 C 160 B 10 0x000020 18 00
32 C 161 B 10 0x00002b + 18 00
33 C 162 B 10 0x000030 0 18 00
34 C 163 B 10 0x000031 1 18 00
35 C 164 B 10 0x000030 0 18 00
36 C 165 B 10 0x000030 0 18 00
37 C 166 B 10 0x000020 18 00
38 C 167 B 10 0x000028 ( 18 00
39 C 168 B 10 0x000033 3 18 00
40 C 169 B 10 0x000020 18 00
41 C 170 B 10 0x000068 h 18 00
42 C 171 B 10 0x00006f o 18 00
43 C 172 B 10 0x000075 u 18 00
44 C 173 B 10 0x000072 r 18 00
45 C 174 B 10 0x000073 s 18 00
46 C 175 B 10 0x00002c , 18 00
47 C 176 B 10 0x000020 18 00
48 C 177 B 10 0x000032 2 18 00
49 C 178 B 10 0x000034 4 18 00
50 C 179 B 10 0x000020 18 00
51 C 180 B 10 0x00006d m 18 00
52 C 181 B 10 0x000069 i 18 00
53 C 182 B 10 0x00006e n 18 00
54 C 183 B 10 0x000075 u 18 00
55 C 184 B 10 0x000074 t 18 00
56 C 185 B 10 0x000065 e 18 00
57 C 186 B 10 0x000073 s 18 00
58 C 187 B 10 0x00002c , 18 00
59 C 188 B 10 0x000020 18 00
60 C 189 B 10 0x000034 4 18 00
61 C 190 B 10 0x000020 18 00
62 C 191 B 10 0x000073 s 18 00
63 C 192 B 10 0x000065 e 18 00
64 C 193 B 10 0x000063 c 18 00
65 C 194 B 10 0x00006f o 18 00
66 C 195 B 10 0x00006e n 18 00
67 C 196 B 10 0x000064 d 18 00
68 C 197 B 10 0x000073 s 18 00
69 C 198 B 10 0x000020 18 00
70 C 199 B 10 0x000061 a 18 00
71 C 200 B 10 0x000067 g 18 00
72 C 201 B 10 0x00006f o 18 00
73 C 202 B 10 0x000029 ) 18 00
74 C 0 0 10 0x000020 18 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
4 204 205 1 010000100000 0 80 10 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 204 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
5 205 228 23 010000100000 0 100 230 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 205 B 10 0x000053 S 0 00
1 C 206 B 10 0x000075 u 0 00
2 C 207 B 10 0x000062 b 0 00
3 C 208 B 10 0x00006d m 0 00
4 C 209 B 10 0x000069 i 0 00
5 C 210 B 10 0x000074 t 0 00
6 C 211 B 10 0x000074 t 0 00
7 C 212 B 10 0x000065 e 0 00
8 C 213 B 10 0x000064 d 0 00
9 C 214 B 10 0x000020 0 00
10 C 215 B 10 0x000062 b 0 00
11 C 216 B 10 0x000079 y 0 00
12 C 217 B 10 0x00003a : 0 00
13 C 218 B 10 0x000020 0 00
14 C 219 B 10 0x000055 U 0 00
15 C 220 B 10 0x00006e n 0 00
16 C 221 B 10 0x00006b k 0 00
17 C 222 B 10 0x00006e n 0 00
18 C 223 B 10 0x00006f o 0 00
19 C 224 B 10 0x000077 w 0 00
20 C 225 B 10 0x00006e n 0 00
21 C 226 B 10 0x000020 0 00
22 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
6 228 229 1 010000100000 0 120 10 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 228 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
7 229 291 62 010000100000 0 140 620 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 229 B 10 0x000054 T 0 00
1 C 230 B 10 0x000061 a 0 00
2 C 231 B 10 0x000067 g 0 00
3 C 232 B 10 0x000067 g 0 00
4 C 233 B 10 0x000065 e 0 00
5 C 234 B 10 0x000064 d 0 00
6 C 235 B 10 0x00003a : 0 00
7 C 236 B 10 0x000020 0 00
8 C 237 B 10 0x000062 b 31 00
9 C 238 B 10 0x000061 a 31 00
10 C 239 B 10 0x000074 t 31 00
11 C 240 B 10 0x000068 h 31 00
12 C 241 B 10 0x000073 s 31 00
13 C 242 B 10 0x000020 0 00
14 C 243 B 10 0x00002c , 0 00
15 C 244 B 10 0x000020 0 00
16 C 245 B 10 0x000073 s 31 00
17 C 246 B 10 0x000069 i 31 00
18 C 247 B 10 0x00006e n 31 00
19 C 248 B 10 0x00006b k 31 00
20 C 249 B 10 0x000073 s 31 00
21 C 250 B 10 0x000020 0 00
22 C 251 B 10 0x00002c , 0 00
23 C 252 B 10 0x000020 0 00
24 C 253 B 10 0x000043 C 31 00
25 C 254 B 10 0x000061 a 31 00
26 C 255 B 10 0x000074 t 31 00
27 C 256 B 10 0x000073 s 31 00
28 C 257 B 10 0x000020 0 00
29 C 258 B 10 0x00002c , 0 00
30 C 259 B 10 0x000020 0 00
31 C 260 B 10 0x000056 V 31 00
32 C 261 B 10 0x000069 i 31 00
33 C 262 B 10 0x000064 d 31 00
34 C 263 B 10 0x000065 e 31 00
35 C 264 B 10 0x00006f o 31 00
36 C 265 B 10 0x000020 0 00
37 C 266 B 10 0x00002c , 0 00
38 C 267 B 10 0x000020 0 00
39 C 268 B 10 0x000062 b 31 00
40 C 269 B 10 0x000065 e 31 00
41 C 270 B 10 0x00006e n 31 00
42 C 271 B 10 0x000067 g 31 00
43 C 272 B 10 0x000061 a 31 00
44 C 273 B 10 0x00006c l 31 00
45 C 274 B 10 0x000020 31 00
46 C 275 B 10 0x000063 c 31 00
47 C 276 B 10 0x000061 a 31 00
48 C 277 B 10 0x000074 t 31 00
49 C 278 B 10 0x000073 s 31 00
50 C 279 B 10 0x000020 0 00
51 C 280 B 10 0x00002c , 0 00
52 C 281 B 10 0x000020 0 00
53 C 282 B 10 0x000062 b 31 00
54 C 283 B 10 0x000061 a 31 00
55 C 284 B 10 0x000074 t 31 00
56 C 285 B 10 0x000068 h 31 00
57 C 286 B 10 0x000069 i 31 00
58 C 287 B 10 0x00006e n 31 00
59 C 288 B 10 0x000067 g 31 00
60 C 289 B 10 0x000020 0 00
61 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
8 291 310 19 010000100000 0 160 190 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 291 B 10 0x000053 S 31 00
1 C 292 B 10 0x000068 h 31 00
2 C 293 B 10 0x000061 a 31 00
3 C 294 B 10 0x000072 r 31 00
4 C 295 B 10 0x000065 e 31 00
5 C 296 B 10 0x000020 31 00
6 C 297 B 10 0x00006f o 31 00
7 C 298 B 10 0x00006e n 31 00
8 C 299 B 10 0x000020 31 00
9 C 300 B 10 0x000046 F 31 00
10 C 301 B 10 0x000061 a 31 00
11 C 302 B 10 0x000063 c 31 00
12 C 303 B 10 0x000065 e 31 00
13 C 304 B 10 0x000062 b 31 00
14 C 305 B 10 0x00006f o 31 00
15 C 306 B 10 0x00006f o 31 00
16 C 307 B 10 0x00006b k 31 00
17 C 308 B 10 0x000020 0 00
18 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
9 310 313 3 010000100000 0 180 30 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 310 B 10 0x00002a * 31 00
1 C 311 B 10 0x000020 0 00
2 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
10 313 314 1 010000100000 0 200 10 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 313 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
11 314 319 5 010000100000 0 220 50 20 20 16 16
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C 314 B 10 0x00004c L 31 00
1 C 315 B 10 0x000069 i 31 00
2 C 316 B 10 0x00006e n 31 00
3 C 317 B 10 0x00006b k 31 00
4 C 0 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
12 319 319 1 010000010000 0 240 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
13 319 319 1 010000010000 0 260 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
14 319 319 1 010000010000 0 280 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
15 319 319 1 010000010000 0 300 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
16 319 319 1 010000010000 0 320 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
17 319 319 1 010000010000 0 340 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
18 319 319 1 010000010000 0 360 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
19 319 319 1 010000010000 0 380 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
20 319 319 1 010000010000 0 400 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
21 319 319 1 010000010000 0 420 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
22 319 319 1 010000010000 0 440 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
23 319 319 1 010000010000 0 460 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
24 319 319 1 010000010000 0 480 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
25 319 319 1 010000010000 0 500 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
26 319 319 1 010000010000 0 520 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
27 319 319 1 010000010000 0 540 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
28 319 319 1 010000010000 0 560 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
29 319 319 1 010000010000 0 580 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
30 319 319 1 010000010000 0 600 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
31 319 319 1 010000010000 0 620 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
32 319 319 1 010000010000 0 640 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
33 319 319 1 010000010000 0 660 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
34 319 319 1 010000010000 0 680 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
35 319 319 1 010000010000 0 700 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
36 319 319 1 010000010000 0 720 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
37 319 319 1 010000010000 0 740 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
38 319 319 1 010000010000 0 760 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
39 319 319 1 010000010000 0 780 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
40 319 319 1 010000010000 0 800 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
41 319 319 1 010000010000 0 820 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
42 319 319 1 010000010000 0 840 10 20 20 16 0
-1 -1 0
-1 -1
-1 -1
Glyph# Type Pos O W Code C Face LR
0 C -1 0 10 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
43 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 23248 0x000052 R 0 11
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
44 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 23248 0x5045eab . 0 01
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
45 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
46 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
47 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
48 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 23248 0x000000 . 0 10
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
49 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 23248 0x000000 . 0 10
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
50 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x10a12eea . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
51 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
52 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
53 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0xb41d5622 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
54 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0xb690beab . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
55 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000006 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
56 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x362f6f74 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
57 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0xde577f38 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
58 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 0 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
59 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814600 0 23248 0x9f5f433b . 0 10
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
60 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
61 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 -14816 0x000000 . 0 11
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
62 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x00000f . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
63 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x7fcffeaa . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
64 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
65 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x5bee652e . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
66 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x7474683f . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
67 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
68 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x000000 . 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
69 0 0 0 000000000000 0 0 0 0 0 0 0
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 140018357814616 0 0 0x000020 0 00
Row Start End Used oE><\CTZFesm X Y W H V A P
==============================================================================
70 0 0 82 010000000000 0 860 829 20 20 16 13
0 0 0
0 0
0 0
Glyph# Type Pos O W Code C Face LR
0 C 0 S 11 0x000020 1 10
1 C 1 S 10 0x000031 1 1 00
2 C 0 S 10 0x00003a : 1 00
3 C 0 S 10 0x00002d - 1 00
4 C 1 S 10 0x00002d - 1 00
5 C 1 S 10 0x00002d - 1 00
6 C 0 S 10 0x000020 1 00
7 C 1 S 10 0x000020 1 00
8 I 0 S 18 0x000000 . 1 00
9 C 5 S 10 0x000020 1 00
10 C 6 S 10 0x00006e n 1 00
11 C 7 S 10 0x000065 e 1 00
12 C 8 S 10 0x000077 w 1 00
13 C 9 S 10 0x000073 s 1 00
14 C 10 S 10 0x00003a : 1 00
15 C 11 S 10 0x000067 g 1 00
16 C 12 S 10 0x00002e . 1 00
17 C 13 S 10 0x000063 c 1 00
18 C 14 S 10 0x00002e . 1 00
19 C 15 S 10 0x000066 f 1 00
20 C 16 S 10 0x00002e . 1 00
21 C 17 S 10 0x000063 c 1 00
22 C 18 S 10 0x000068 h 1 00
23 C 19 S 10 0x000065 e 1 00
24 C 20 S 10 0x000065 e 1 00
25 C 21 S 10 0x00007a z 1 00
26 C 22 S 10 0x000062 b 1 00
27 C 23 S 10 0x000075 u 1 00
28 C 24 S 10 0x000072 r 1 00
29 C 25 S 10 0x000067 g 1 00
30 C 26 S 10 0x000065 e 1 00
31 C 27 S 10 0x000072 r 1 00
32 C 28 S 10 0x000020 1 00
33 C 29 S 10 0x000042 B 1 00
34 C 30 S 10 0x000061 a 1 00
35 C 31 S 10 0x000074 t 1 00
36 C 32 S 10 0x000068 h 1 00
37 C 33 S 10 0x000020 1 00
38 C 34 S 10 0x000054 T 1 00
39 C 35 S 10 0x000069 i 1 00
40 C 36 S 10 0x00006d m 1 00
41 C 37 S 10 0x000065 e 1 00
42 C 38 S 10 0x000020 1 00
43 C 39 S 10 0x000066 f 1 00
44 C 40 S 10 0x00006f o 1 00
45 C 41 S 10 0x000072 r 1 00
46 C 42 S 10 0x000020 1 00
47 C 43 S 10 0x00004d M 1 00
48 C 44 S 10 0x00006f o 1 00
49 C 45 S 10 0x000077 w 1 00
50 C 46 S 10 0x000067 g 1 00
51 C 47 S 10 0x00002e . 1 00
52 C 48 S 10 0x00002e . 1 00
53 C 49 S 10 0x00002e . 1 00
54 C 0 S 10 0x000020 1 00
55 C 1 S 10 0x000020 1 00
56 C 2 S 10 0x000020 1 00
57 C 1 S 10 0x000041 A 1 00
58 C 1 S 10 0x00006c l 1 00
59 C 1 S 10 0x00006c l 1 00
60 C 0 S 10 0x000020 1 00
61 C 1 S 10 0x00004c L 1 00
62 C 3 S 10 0x000035 5 1 00
63 C -1 - 10 0x000020 1 00
64 C -1 - 10 0x000020 1 00
65 C -1 - 10 0x000020 1 00
66 C 0 S 10 0x000020 1 00
67 C 1 S 10 0x000020 1 00
68 C 0 S 10 0x000028 ( 1 00
69 C 0 S 10 0x000041 A 1 00
70 C 1 S 10 0x000072 r 1 00
71 C 2 S 10 0x000074 t 1 00
72 C 3 S 10 0x000069 i 1 00
73 C 4 S 10 0x000063 c 1 00
74 C 5 S 10 0x00006c l 1 00
75 C 6 S 10 0x000065 e 1 00
76 C 0 S 10 0x000029 ) 1 00
77 C 0 S 10 0x000020 1 00
78 C 0 - 10 0x000020 1 00
79 C -1 - 10 0x000020 1 00
80 C -1 - 10 0x000020 1 00
81 C -1 - 10 0x000020 1 01
redisplay_internal 0
0x5da9f78 (article): same window start
0x5da9f78 (article): 1
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x32789a8 (*Summary nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): same window start
0x39a11e0 (*Article nntp+news.gmane.org:gwene.com.feedburner.cheezburger*): 1

redisplay_internal 0
0x5da9f78 (article): same window start
0x5da9f78 (article): 1
0x39a11e0 (*Group*): forced window start

0x5da9f78 (article): same window start
0x5da9f78 (article): 1
0x39a11e0 (*Group*): same window start
0x39a11e0 (*Group*): 1
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1
redisplay_internal 0
0x10e8590 ( *Minibuf-1*): same window start
0x10e8590 ( *Minibuf-1*): 1

redisplay_preserve_echo_area (8)
redisplay_internal 0
trying display optimization 1

0x10e8590 ( *Minibuf-1*): optimization 1

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Cc: Andreas Schwab <sch...@linux-m68k.org>, 10...@debbugs.gnu.org
> Date: Tue, 08 Jan 2013 06:11:34 +0100

I think I do understand. My suspicion is that we somehow fail to
realize that the screen estate formerly occupied by the image, and
everything that follows it, needs to be cleared in its entirety. On
the display engine level, the image takes just one "line" (called
"glyph row"), and perhaps we somehow don't realize that the height of
that "line" is large, and all of that needs to be cleared, not just
the number of text lines of "normal" height that will replace the
image on display.

Thanks for the details, they confirm my suspicions. I now need to
find whodunit in the code...

[Michael Albinus]

Eli Zaretskii <el...@gnu.org> writes:

> Thanks for the details, they confirm my suspicions. I now need to
> find whodunit in the code...

If you need more data: on one of my laptops I can easily reproduce this
bug. Just tell me, whether I shall produce more debug info for you.

Best regards, Michael.

[Eli Zaretskii]

> From: Michael Albinus <michael...@gmx.de>
> Cc: Lars Magne Ingebrigtsen <la...@gnus.org>, 10...@debbugs.gnu.org, sch...@linux-m68k.org
> Date: Tue, 08 Jan 2013 12:19:14 +0100

>
> If you need more data: on one of my laptops I can easily reproduce this
> bug. Just tell me, whether I shall produce more debug info for you.

What I'd really like is a reproducible recipe. Can you come up with
one?

[Michael Albinus]

Eli Zaretskii <el...@gnu.org> writes:

> What I'd really like is a reproducible recipe. Can you come up with
> one?

Nothing general. I'm in the bad situation, that one of my laptops (at
work) produces the display bug permanently. Often, just scrolling or
page up/down is sufficient. That Emacs stanza is almost useless for me,
but there's no recipe for reproducing outside that machine.

Maybe we could arrange that I take it home, and provide you access. Over
night, or over weekend. Let me know.

Best regards, Michael.

[Eli Zaretskii]

> From: Michael Albinus <michael...@gmx.de>
> Cc: la...@gnus.org, 10...@debbugs.gnu.org, sch...@linux-m68k.org
> Date: Tue, 08 Jan 2013 22:29:59 +0100

>
> Maybe we could arrange that I take it home, and provide you access. Over
> night, or over weekend. Let me know.

Weekend is better, thanks.

[Eli Zaretskii]

> Date: Tue, 08 Jan 2013 07:43:50 +0200
> From: Eli Zaretskii <el...@gnu.org>
> Cc: 10...@debbugs.gnu.org, sch...@linux-m68k.org

>
> I think I do understand. My suspicion is that we somehow fail to
> realize that the screen estate formerly occupied by the image, and
> everything that follows it, needs to be cleared in its entirety. On
> the display engine level, the image takes just one "line" (called
> "glyph row"), and perhaps we somehow don't realize that the height of
> that "line" is large, and all of that needs to be cleared, not just
> the number of text lines of "normal" height that will replace the
> image on display.
>

> Thanks for the details, they confirm my suspicions. I now need to
> find whodunit in the code...

Please apply the patch below and run with it for a while. It makes
the output of trace-redisplay more voluminous, but I don't see how
else we could catch the problem. When the problem happens again,
please post the results.

Here's my analysis of what is involved; perhaps it will help you read
the output and make some changes on the spot, if needed.

The clearing of portions of display that no longer display anything is
done as part of dispnew.c:update_window. It does that as part of the
call to update_window_line, when the latter is passed a screen line
(a.k.a. "row") that should be empty on display. Such empty lines have
a single glyph (an "invented" blank character with charpos equal to
point-max), whose sole purpose is to facilitate clearing of empty
lines. These empty lines have the enabled_p flag set, which means
they should be displayed. (update_window ignores lines whose
enabled_p flag is reset, because these do not correspond to any part
of the displayed text.)

So, for us to fail to clear these empty lines, I see several possible
reasons:

. the logic in update_window somehow skips the loop that starts at
line 3495 and which displays the empty lines past the end of the
buffer; or

. some redisplay optimization in xdisp.c decides that those parts of
display do not need to be updated, and thus excludes them from the
glyph matrix it constructs in w->desired_matrix, so that those
lines are not updated by update_window; or

. the function x_clear_end_of_line, which is called by
update_window_line, or its terminal-specific back-end (e.g.,
xterm.c:x_clear_frame_area), which implements the meat of that
function, somehow fail to clear the correct portion of the display.

The patches below are designed to report enough info for us to be able
to tell which of the above hypotheses, if any, is true.

Btw, any idea when these problems started happening? Is it an old
problem, or did it start to appear only recently?

Thanks.

Here are the patches:

--- src/dispnew.c~0 2013-01-07 14:13:25.000000000 +0200
+++ src/dispnew.c 2013-01-13 14:22:21.549690800 +0200
@@ -3473,6 +3473,11 @@
while (row < end && !row->enabled_p)
++row;

+ TRACE ((stderr,
+ "update_window: first enabled: %d, last: %d, no_scrolling: %d\n",
+ row - desired_matrix->rows, end - desired_matrix->rows - 1,
+ desired_matrix->no_scrolling_p));
+
/* Try reusing part of the display by copying. */
if (row < end && !desired_matrix->no_scrolling_p)
{
@@ -3481,6 +3486,7 @@
{
/* All rows were found to be equal. */
paused_p = 0;
+ TRACE ((stderr, "scrolling_window found all rows equal\n"));
goto set_cursor;
}
else if (rc > 0)
@@ -3488,10 +3494,18 @@
/* We've scrolled the display. */
force_p = 1;
changed_p = 1;
+ TRACE ((stderr, "scrolling_window scrolled the display\n"));
}
}

/* Update the rest of the lines. */
+ if (!(row < end && (force_p || !input_pending)))
+ {
+ TRACE ((stderr,
+ "NOT updating rest of lines; row = %d end = %d fp = %d ip = %d\n",
+ row - desired_matrix->rows, end - desired_matrix->rows - 1,
+ force_p, input_pending));
+ }
for (; row < end && (force_p || !input_pending); ++row)
/* scrolling_window resets the enabled_p flag of the rows it
reuses from current_matrix. */
@@ -3533,12 +3547,17 @@
tempted to optimize redisplay based on lines displayed
in the first redisplay. */
if (MATRIX_ROW_BOTTOM_Y (row) >= yb)
- for (i = vpos + 1; i < w->current_matrix->nrows - 1; ++i)
- MATRIX_ROW (w->current_matrix, i)->enabled_p = 0;
+ {
+ TRACE ((stderr, "update_window marks rows %d - %d invalid\n",
+ vpos + 1, w->current_matrix->nrows - 2));
+ for (i = vpos + 1; i < w->current_matrix->nrows - 1; ++i)
+ MATRIX_ROW (w->current_matrix, i)->enabled_p = 0;
+ }
}

/* Was display preempted? */
paused_p = row < end;
+ TRACE ((stderr, "update_window %spreempted\n", paused_p ? "" : "NOT "));

set_cursor:



--- src/xdisp.c~0 2013-01-07 14:13:25.000000000 +0200
+++ src/xdisp.c 2013-01-13 16:14:15.697145600 +0200
@@ -25568,6 +25568,9 @@
from_y = WINDOW_TO_FRAME_PIXEL_Y (w, max (min_y, output_cursor.y));
to_y = WINDOW_TO_FRAME_PIXEL_Y (w, to_y);

+ TRACE ((stderr, "clear_frame_area: [%d - %d] [%d - %d]\n",
+ from_x, to_x, from_y, to_y));
+
/* Prevent inadvertently clearing to end of the X window. */
if (to_x > from_x && to_y > from_y)
{

[Michael Albinus]

Michael Albinus <michael...@gmx.de> writes:

>> Could just summarize what idiosyncrasies do you remember seeing on
>> that machine? Like in which parts of the display/window do these
>> artifacts appear, and which part(s) of a line did you observe
>> garbled? E.g., is it always the beginning of a line?
>
> I'll check tomorrow more systematically.

Bisecting my ~/.emacs, the following form provokes the display error for me:

(add-to-list 'default-frame-alist
'(font . "-misc-fixed-bold-r-normal-*-15-*-iso8859-1"))

On other machines, there is the same ~/.emacs w/o problems. On the
machine in question, I have two matching fonts:

-misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1
-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1

Does this tell you anything?

Best regards, Michael.

[Eli Zaretskii]

> From: Michael Albinus <michael...@gmx.de>
> Cc: 10...@debbugs.gnu.org
> Date: Thu, 27 Jun 2013 15:20:31 +0200

>
> Bisecting my ~/.emacs, the following form provokes the display error for me:
>
> (add-to-list 'default-frame-alist
> '(font . "-misc-fixed-bold-r-normal-*-15-*-iso8859-1"))
>
> On other machines, there is the same ~/.emacs w/o problems. On the
> machine in question, I have two matching fonts:
>
> -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1
> -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
>
> Does this tell you anything?

Not really, unfortunately: I know very little about fonts and how
Emacs uses them.

But if we continue your line of investigation: does removing one of
these fonts solve the problem with the original ~/.emacs?

[Michael Albinus]

Eli Zaretskii <el...@gnu.org> writes:

> But if we continue your line of investigation: does removing one of
> these fonts solve the problem with the original ~/.emacs?

I'll check on Monday in the office; I'm on the road now.

Best regards, Michael.

[Eli Zaretskii]

> From: Michael Albinus <michael...@gmx.de>
> Cc: 10...@debbugs.gnu.org

> Date: Tue, 09 Jul 2013 12:39:17 +0200

>
> >> Bisecting my ~/.emacs, the following form provokes the display error for me:
> >>
> >> (add-to-list 'default-frame-alist
> >> '(font . "-misc-fixed-bold-r-normal-*-15-*-iso8859-1"))
> >>
> >> On other machines, there is the same ~/.emacs w/o problems. On the
> >> machine in question, I have two matching fonts:
> >>
> >> -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1
> >> -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
>

> > But if we continue your line of investigation: does removing one of
> > these fonts solve the problem with the original ~/.emacs?
>

> It happens for both fonts. I've tested
>
> (add-to-list 'default-frame-alist
> '(font . "-misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1"))
>
> and
>
> (add-to-list 'default-frame-alist
> '(font . "-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1"))
>
> Anyway, here is a recipe for reproduction:
>
> 1. C-x C-f "a larger file, with a no space in last line, first col"
> 2. M->
> 3. C-p
> 4. Use mouse wheel to scroll buffer up

Thanks. Unfortunately, I cannot use these font definitions on
Windows. Does anyone know the Windows equivalents?

[Eli Zaretskii]

> From: Michael Albinus <michael...@gmx.de>
> Cc: 10...@debbugs.gnu.org
> Date: Tue, 09 Jul 2013 12:39:17 +0200
>

> >> -misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1
> >> -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1
>
> > But if we continue your line of investigation: does removing one of
> > these fonts solve the problem with the original ~/.emacs?
>
> It happens for both fonts. I've tested
>
> (add-to-list 'default-frame-alist
> '(font . "-misc-fixed-bold-r-normal--15-120-100-100-c-90-iso8859-1"))
>
> and
>
> (add-to-list 'default-frame-alist
> '(font . "-misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1"))
>
> Anyway, here is a recipe for reproduction:
>
> 1. C-x C-f "a larger file, with a no space in last line, first col"
> 2. M->
> 3. C-p
> 4. Use mouse wheel to scroll buffer up
>

> It doesn't happen always, but often. Depends on redisplay calls, I
> suspect. See enclosures, which show a superfluous "(".

I tried to reproduce this, including installing and using a misc-fixed
font, but couldn't see any such artifacts left after scroll.

Do you see the problem with these fonts on a different system?

Does anyone else see this?

[Michael Albinus]

Eli Zaretskii <el...@gnu.org> writes:

> I tried to reproduce this, including installing and using a misc-fixed
> font, but couldn't see any such artifacts left after scroll.
>
> Do you see the problem with these fonts on a different system?

Nope. I see it only on this laptop @work.

If you have an idea for instructing the display engine with trace
messages, just tell me. Or how to debug.

Best regards, Michael.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> I think I do understand. My suspicion is that we somehow fail to
> realize that the screen estate formerly occupied by the image, and
> everything that follows it, needs to be cleared in its entirety. On
> the display engine level, the image takes just one "line" (called
> "glyph row"), and perhaps we somehow don't realize that the height of
> that "line" is large, and all of that needs to be cleared, not just
> the number of text lines of "normal" height that will replace the
> image on display.

Did you get any further on this?

I've finally found a single message in Gnus where I can reproduce this
almost 100% of the time -- but only on this display, so it's probably
closely tied to the exact geometry of the Emacs frame.

But if you have debugging instructions, since I can now reproduce this,
I can hopefully give you the output you need to fix this...

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Cc: 10...@debbugs.gnu.org, sch...@linux-m68k.org
> Date: Fri, 14 Nov 2014 16:45:38 +0100

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > I think I do understand. My suspicion is that we somehow fail to
> > realize that the screen estate formerly occupied by the image, and
> > everything that follows it, needs to be cleared in its entirety. On
> > the display engine level, the image takes just one "line" (called
> > "glyph row"), and perhaps we somehow don't realize that the height of
> > that "line" is large, and all of that needs to be cleared, not just
> > the number of text lines of "normal" height that will replace the
> > image on display.
>
> Did you get any further on this?

No.

> I've finally found a single message in Gnus where I can reproduce this
> almost 100% of the time -- but only on this display, so it's probably
> closely tied to the exact geometry of the Emacs frame.
>
> But if you have debugging instructions, since I can now reproduce this,
> I can hopefully give you the output you need to fix this...

Can you run with the patch I posted back then, and report the output,
together with a screenshot of the offending display corruption (so I
could match the debugging output with what was on the screen)?

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> Can you run with the patch I posted back then, and report the output,
> together with a screenshot of the offending display corruption (so I
> could match the debugging output with what was on the screen)?

Will do. I'll try to get it done tomorrow.

[Lars Magne Ingebrigtsen]

D'oh. I dumped the glyphs in the wrong buffer.

I'll do another one.

[Lars Magne Ingebrigtsen]

Ok, here are the two new traces. The first one is when everything is OK.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>
> Cc: 10...@debbugs.gnu.org

> Date: Sat, 15 Nov 2014 16:41:23 +0100

>
> Ok, here are the two new traces. The first one is when everything is OK.

Sorry for a long delay.

Unfortunately, I cannot match either of your two images with the
corresponding dump of the glyph matrix: there are small
inconsistencies in both the "OK" and the "not OK" cases. For example,
the first image shows "Top L1" in the mode line of the window that
displays the article, but the matrix dump says:

68: (1) ' 1:--- . news:g.c.w.arnoldzwicky Austenian humbleb... Top L19 (Article) '

which is line 19. This is a minor discrepancy, but since there are
many similar discrepancies, some of which are probably parts of the
bug, I feel I have no firm ground from which I can begin studying the
data and making hypotheses about what went wrong.

Could you please produce 2 sets of screenshot+matrix dump which are
coherent with each other? I must be sure that when I see a
discrepancy, it is part of the bug, not some artifact that needs to be
ignored.

Also, I don't understand the second screenshot: which parts of it are
correct and which are bogus? The text before the image looks
unfinished, but its continuation, starting with screen line 20, which
is clearly present in the glyph matrix dump, is not shown. Are you
saying that Emacs was supposed to display that continuation, but never
did, and instead left the old parts on display?

Thanks.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>
> Cc: 10...@debbugs.gnu.org

> Date: Tue, 02 Dec 2014 18:01:08 +0100
>
> I've produced four screenshots instead, which should make it clearer
> what it's supposed to look like, and what's the bug.
>
> First, I've selected the article, and it's displaying the topmost part
> of the article, and everything is fine.

Thanks, and sorry again for a _really_ long delay.

Based on the stuff you collected and the screenshots, it sounds like
Emacs doesn't clear and doesn't redraw the parts of the screen which
become corrupted, amazing as that sounds. The only difference between
the "good" and the "bad" output is that in the latter case, for some
reason, Emacs stops clearing and redrawing screen lines below some Y
coordinate, and all the stuff which was there before that stays put
instead of being replaced by the new stuff.

I'd like to prepare an additional patch which will allow you to
collect more data that might reveal why Emacs behaves like that. In
order to test the patch, is it possible for you to give me
instructions for how to display that article, starting from "emacs -Q"?

Thanks in advance. I think we are making progress, albeit slowly (my
fault, not yours).

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> I'd like to prepare an additional patch which will allow you to
> collect more data that might reveal why Emacs behaves like that. In
> order to test the patch, is it possible for you to give me
> instructions for how to display that article, starting from "emacs -Q"?

That was easier than I had thought. I had forgotten about this entry
point to Gnus.

`eval'-ing this from "emacs -Q" should work:

(gnus-fetch-group "nntp+news.gmane.org:gwene.com.wordpress.arnoldzwicky" '(3401))

although you will be queried about the self-signed certificate.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>
> Cc: 10...@debbugs.gnu.org

> Date: Fri, 16 Jan 2015 00:50:53 +0100

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > I'd like to prepare an additional patch which will allow you to
> > collect more data that might reveal why Emacs behaves like that. In
> > order to test the patch, is it possible for you to give me
> > instructions for how to display that article, starting from "emacs -Q"?
>
> That was easier than I had thought. I had forgotten about this entry
> point to Gnus.
>
> `eval'-ing this from "emacs -Q" should work:
>
> (gnus-fetch-group "nntp+news.gmane.org:gwene.com.wordpress.arnoldzwicky" '(3401))
>
> although you will be queried about the self-signed certificate.

Thanks, that was easy enough. Granted, I don't see any redisplay
problems with that article, like you do.

Below please find a new patch to add trace data. This is _instead_ of
the previous patch, not in addition to it, and it's relative to the
current master (I hope the problem is still visible with the current
master).

After applying the patch, please again do whatever is needed to
reproduce the problem, and please tell me which part(s) of the trace
are emitted when the display becomes corrupted.

Before invoking "M-x trace-redisplay", please disable
blink-cursor-mode (as it triggers too many unnecessary redisplay
cycles that muddy the water), and also delete ("C-x 0") the summary
window, so that redisplay has less windows to refresh (which will
again make the signal to noise ratio of the trace better).

Thanks.

Here's the patch:

diff --git a/src/dispnew.c b/src/dispnew.c
index a643d58..c41584d 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -3606,6 +3606,8 @@ struct glyph_row *
TEXT_AREA, desired_row->used[TEXT_AREA]);

/* Clear to end of window. */
+ TRACE ((stderr, "clear_end_of_line1(%d..): vpos = %d Y = %d\n",
+ desired_row->used[TEXT_AREA], vpos, desired_row->y));
rif->clear_end_of_line (w, updated_row, TEXT_AREA, -1);
changed_p = 1;

@@ -3642,6 +3644,8 @@ struct glyph_row *
i = 0;
x = desired_row->x;

+ TRACE ((stderr, "detect common glyphs for row at vpos = %d\n", vpos));
+
/* Loop over glyphs that current and desired row may have
in common. */
while (i < stop)
@@ -3743,6 +3747,8 @@ struct glyph_row *
}

output_cursor_to (w, vpos, start_hpos, desired_row->y, start_x);
+ TRACE ((stderr, "write different glyphs %d..%d at vpos = %d\n",
+ start_hpos, i, vpos));
rif->write_glyphs (w, updated_row, start,
TEXT_AREA, i - start_hpos);
changed_p = 1;
@@ -3753,6 +3759,8 @@ struct glyph_row *
if (i < desired_row->used[TEXT_AREA])
{
output_cursor_to (w, vpos, i, desired_row->y, x);
+ TRACE ((stderr, "write the rest %d..%d at vpos = %d\n",
+ i, desired_row->used[TEXT_AREA], vpos));
rif->write_glyphs (w, updated_row, desired_glyph,
TEXT_AREA, desired_row->used[TEXT_AREA] - i);
changed_p = 1;
@@ -3769,6 +3777,7 @@ struct glyph_row *
|| ((desired_row->used[TEXT_AREA]
== current_row->used[TEXT_AREA])
&& MATRIX_ROW_EXTENDS_FACE_P (current_row)));
+ TRACE ((stderr, "nothing to clear at vpos = %d\n", vpos));
}
else if (MATRIX_ROW_EXTENDS_FACE_P (current_row))
{
@@ -3776,6 +3785,8 @@ struct glyph_row *
if (i >= desired_row->used[TEXT_AREA])
output_cursor_to (w, vpos, i, desired_row->y,
desired_row->pixel_width);
+ TRACE ((stderr, "clear_end_of_line2(%d..): vpos = %d Y = %d\n",
+ i, vpos, desired_row->y));
rif->clear_end_of_line (w, updated_row, TEXT_AREA, -1);
changed_p = 1;
}
@@ -3804,6 +3815,8 @@ struct glyph_row *
}
else
xlim = current_row->pixel_width;
+ TRACE ((stderr, "clear_end_of_line3(%d..): vpos = %d Y = %d\n",
+ i, vpos, desired_row->y));
rif->clear_end_of_line (w, updated_row, TEXT_AREA, xlim);
changed_p = 1;
}
diff --git a/src/xdisp.c b/src/xdisp.c
index f006f8e..b70ee7a 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -27178,6 +27178,9 @@ and buffer to use as the context for the formatting (defaults
from_y = WINDOW_TO_FRAME_PIXEL_Y (w, max (min_y, w->output_cursor.y));

[Eli Zaretskii]

> Date: Sat, 17 Jan 2015 13:34:17 +0200

> From: Eli Zaretskii <el...@gnu.org>
> Cc: 10...@debbugs.gnu.org
>

> > From: Lars Magne Ingebrigtsen <la...@gnus.org>
> > Cc: 10...@debbugs.gnu.org
> > Date: Fri, 16 Jan 2015 00:50:53 +0100
> >
> > Eli Zaretskii <el...@gnu.org> writes:
> >
> > > I'd like to prepare an additional patch which will allow you to
> > > collect more data that might reveal why Emacs behaves like that. In
> > > order to test the patch, is it possible for you to give me
> > > instructions for how to display that article, starting from "emacs -Q"?
> >
> > That was easier than I had thought. I had forgotten about this entry
> > point to Gnus.
> >
> > `eval'-ing this from "emacs -Q" should work:
> >
> > (gnus-fetch-group "nntp+news.gmane.org:gwene.com.wordpress.arnoldzwicky" '(3401))
> >
> > although you will be queried about the self-signed certificate.
>
> Thanks, that was easy enough. Granted, I don't see any redisplay
> problems with that article, like you do.
>
> Below please find a new patch to add trace data. This is _instead_ of
> the previous patch, not in addition to it, and it's relative to the
> current master (I hope the problem is still visible with the current
> master).

Could you perhaps see if this bug still exists in the latest master?
It's possible that the changes in commit d89687b fixed it.

Thanks.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <el...@gnu.org> writes:

> Could you perhaps see if this bug still exists in the latest master?
> It's possible that the changes in commit d89687b fixed it.

I'm no longer able to reproduce this bug, so I think you've nailed it!
Thanks!

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <la...@gnus.org>

> Cc: 10304...@debbugs.gnu.org
> Date: Mon, 11 May 2015 15:06:54 +0200

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> > Could you perhaps see if this bug still exists in the latest master?
> > It's possible that the changes in commit d89687b fixed it.
>
> I'm no longer able to reproduce this bug, so I think you've nailed it!
> Thanks!

Great, thanks for testing.