bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9324: 24.0.50; Movement past end of screen causes weird jump


From: Eli Zaretskii
Subject: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Sat, 20 Aug 2011 14:29:18 +0300

> From: Ivan Andrus <darthandrus@gmail.com>
> Date: Sat, 20 Aug 2011 09:33:31 +0200
> Cc: antoine.levitt@gmail.com,
>  9324@debbugs.gnu.org
> 
> >> 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.

Neither.  The top line in the window is this:

  (custom-set-faces '(mode-line ((t (:box (:line-width 1))))))

If you see something else, your frame must be much larger than mine.

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

Tried 4, same result.

> 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

2418 is the last character in the buffer.  How in the world did you
get there in the first place?  You were supposed to be at line 22,
which begins at character position 1224 and ends at position 1238.  So
where did 2418 come from?

What is the value of `lpoint' after line 14682?  What is the value of
`opoint' after line 14764?  And what is the value of `startp' at line
14886?

> To be honest I'm not sure how new_vpos was set since the other breakpoints 
> are not triggered after having evaluated forward-sexp.

Is your build optimized or not?  If the former, you cannot rely on
every breakpoint you set to trigger, because the compiler rearranges
code to make some of them be set on addresses that are never executed.

Anyway, you should be able to tell which of the conditions got
new_vpos set by looking at the values of w->cursor.vpos and
w->frozen_window_start_p.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]