GNU bug report logs - #9324
24.0.50; Movement past end of screen causes weird jump

Previous Next

Package: emacs;

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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org
Subject: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Sat, 20 Aug 2011 10:37:25 -0400
> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Sat, 20 Aug 2011 14:29:30 +0200
> 
> >> 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.
> 
> But it should have set up the frame size to be the same!?  I have
> 
> (cons (frame-parameter nil 'height) (frame-parameter nil 'width))
> (47 . 89)
> 
> Does setting the frame size not work the same way in Windows?

No, it works the same.  However, AFAIR you cannot trust changes in
frame parameters to take effect immediately, only on the next
redisplay cycle.  If you evaluate the frame parameter changes before
the progn, does the problem still happen?

> Sorry, I started debugging immediately after I evaluated the forward-sexp so that's where the point ought to be.

But then what you observed in the debugger is not related at all to
the issue at hand, does it?

> lpoint and opoint were optimized away, but FWIW I got the following in both situations:
> 
> (gdb) ppt
> BUF PT: 2418 of 1..2419 GAP: 2419 SZ=2000
> 
> 
> (gdb) p startp
> $3 = {
>   charpos = 0, 
>   bytepos = 4320351914
> }

I don't believe these values, I'm quite sure they are wrong because
the build is optimized.

> > 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.
> 
> (gdb) p w->cursor.vpos
> $6 = -1
> (gdb) p w->frozen_window_start_p
> $7 = 0
> 
> so that means new_vpos = window_box_height (w) / 2;

I will only believe what the debugger shows in a non-optimized build.
Please use "-ggdb -g3" in the compiler switches, to force GCC to
produce as much debug info as possible.




This bug report was last modified 13 years and 269 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.