GNU bug report logs -
#9324
24.0.50; Movement past end of screen causes weird jump
Previous Next
Reported by: Ivan Andrus <darthandrus <at> gmail.com>
Date: Thu, 18 Aug 2011 20:51:01 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #38 received at 9324 <at> debbugs.gnu.org (full text, mbox):
On Aug 19, 2011, at 9:06 PM, Eli Zaretskii wrote:
>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Fri, 19 Aug 2011 20:38:09 +0200
>> Cc: antoine.levitt <at> gmail.com,
>> 9324 <at> debbugs.gnu.org
>>
>> Okay, I think I can reliably reproduce it now. Sorry it took so long to get it right. Anyway it seems to require both highlight-parentheses-mode and hl-sexp-mode as well as a custom mode-line face. I invoke it with:
>>
>> emacs -Q -l ~/.emacs.d/elpa/highlight-parentheses-1.0.1/highlight-parentheses.el -l ~/.emacs.d/local/hl-sexp.el ~/vcs/emacs/bug-example-3.el
>
> Sorry to disappoint you, but I cannot reproduce this even with this
> precise recipe. I downloaded the latest hl-sexp.el and
> highlight-parentheses.el, and used them exactly as shown, albeit the
> leading directories were different, and I still cannot see the
> problem. Emacs behaves as expected.
Aaargh! After running the progn, do you see all of line starting with 208, or just the continuation of it. How about increasing the :line-width? If I increase it to 8 I stop seeing the buggy behavior, so maybe at 4 you can see it?
I was able to step through redisplay_window and watch where point changes from
BUF PT: 2418 of 1..2419 GAP: 2419 SZ=2000
to
BUF PT: 1224 of 1..2419 GAP: 2419 SZ=2000
Here's what I did. I have done it a few times now, so if you need me to look at other data I can.
cd ~/vcs/emacs/local/src/
gdb $EMACS
break xdisp.c:14951
break xdisp.c:14939
break xdisp.c:14946
run -Q -l ~/.emacs.d/elpa/highlight-parentheses-1.0.1/highlight-parentheses.el -l ~/.emacs.d/local/hl-sexp.el ~/vcs/emacs/bug-example-3.el
interact with emacs evaluating the font and progn blocks continuing as necessary. Evaluate the forward-sexp and then start stepping through with emacs:
Breakpoint 3, redisplay_window (window=4307577381, just_this_one_p=0) at xdisp.c:14951
14951 if (new_vpos >= 0)
(gdb) p new_vpos
$1 = 336
(gdb) list
14946 new_vpos = window_box_height (w);
14947 }
14948
14949 /* If we need to move point for either of the above reasons,
14950 now actually do it. */
14951 if (new_vpos >= 0)
14952 {
14953 struct glyph_row *row;
14954
14955 row = MATRIX_FIRST_TEXT_ROW (w->desired_matrix);
(gdb)
14956 while (MATRIX_ROW_BOTTOM_Y (row) < new_vpos)
14957 ++row;
14958
14959 TEMP_SET_PT_BOTH (MATRIX_ROW_START_CHARPOS (row),
14960 MATRIX_ROW_START_BYTEPOS (row));
14961
14962 if (w != XWINDOW (selected_window))
14963 set_marker_both (w->pointm, Qnil, PT, PT_BYTE);
14964 else if (current_buffer == old)
14965 SET_TEXT_POS (lpoint, PT, PT_BYTE);
(gdb) n
14955 row = MATRIX_FIRST_TEXT_ROW (w->desired_matrix);
(gdb) n
14956 while (MATRIX_ROW_BOTTOM_Y (row) < new_vpos)
(gdb) prow
y=0 x=0 pwid=112 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=16 R=0
start=90 end=106 ENA DISP
(gdb) n 40
14956 while (MATRIX_ROW_BOTTOM_Y (row) < new_vpos)
(gdb) n
14957 ++row;
(gdb)
14956 while (MATRIX_ROW_BOTTOM_Y (row) < new_vpos)
(gdb)
14957 ++row;
(gdb)
14956 while (MATRIX_ROW_BOTTOM_Y (row) < new_vpos)
(gdb)
14959 TEMP_SET_PT_BOTH (MATRIX_ROW_START_CHARPOS (row),
(gdb) prow
y=330 x=0 pwid=105 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=15 R=0
start=1224 end=1239 ENA DISP
(gdb) ppt
BUF PT: 2418 of 1..2419 GAP: 2419 SZ=2000
(gdb) n
14962 if (w != XWINDOW (selected_window))
(gdb) prow
y=330 x=0 pwid=105 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=15 R=0
start=1224 end=1239 ENA DISP
(gdb) ppt
BUF PT: 1224 of 1..2419 GAP: 2419 SZ=2000
To be honest I'm not sure how new_vpos was set since the other breakpoints are not triggered after having evaluated forward-sexp. The breakpoint on "new_vpos = window_box_height (w) / 2;" is hit, but after evaluating the progn, so I'm confused. Of course I have no idea if I'm even asking the right questions, but maybe you can tell me what else I need to look at.
-Ivan
This bug report was last modified 13 years and 268 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.