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

[Antoine Levitt]

19/08/11 18:19, Ivan Andrus
> On Aug 19, 2011, at 12:41 PM, Eli Zaretskii wrote:
>>> From: Ivan Andrus <darthandrus@gmail.com>
>>> Date: Fri, 19 Aug 2011 12:02:58 +0200
>>> Cc: Antoine Levitt <antoine.levitt@gmail.com>,
>>> 9324@debbugs.gnu.org
>>> 
>>> I just noticed something.  I use `hl-sexp-mode' from
>>> http://edward.oconnor.cx/elisp/hl-sexp.el to highlight the current
>>> sexp that I am in (or touching if at the top level).  This means
>>> when point is right after a top level sexp that sexp is
>>> highlighted.  Immediately after running the forward-sexp the
>>> defadvice sexp is highlighted.
>> 
>> Didn't you say that all this happens in "emacs -Q"?  Then how come
>> hl-sexp happens to be loaded?
>
> Sorry for the confusion.  Of course this doesn't happen with emacs -Q,
> only when running it with my .emacs.  I just thought it might be
> helpful.
>
>>> Of course, any sort of movement changes the highlighting, but it seems to 
>>> indicate that:
>>> 
>>> 1. it moves point correctly
>>> 2. realizes that it has to recenter
>>> 3. recenters the cursor but not the buffer display.
>> 
>> With your original recipe, and without loading hl-sexp in any way,
>> what does "C-x =" say about point, after running forward-sexp?
>
>
> Ah.  Well today starting from emacs -Q I can't reproduce it.  However,
> if I load my .emacs I still can't reproduce it in that same emacs.
> One difference that I notice today is that after running the progn I
> can read the top line namely "208. ..." instead of only the
> continuation of that line.  I swear it worked yesterday, that is that
> I saw the bug in emacs -Q.

Different font/frame size settings?

>
> In case you are interested in what happens in my contaminated emacs,
> if I run C-x = after (forward-sexp) then it says a left parenthesis,
> but if I use `(progn (forward-sexp)(what-cursor-position))` then it
> says the next character is C-j.  Furthermore, changing it to (prog2
> (forward-sexp) (what-cursor-position) (redisplay)) causes it to work
> properly (i.e. no bug).
>
> I guess I'm probably on my own on this one, since even I can't
> reproduce it reliably in emacs -Q, so what functions that I should
> start debugging?

As a general rule, if you can reproduce it reliably with your .emacs,
you probably want to bisect your .emacs (comment out half your .emacs,
seeing if that triggers the bug, and so on until you pinpoint the
setting responsible for the bug)

FWIW, I now remember I had the very same kind of symptoms editing my
.newsrc.eld (very long lines in emacs-lisp mode). I just managed to
reproduce it from emacs -Q with highlight-parentheses
(http://nschum.de/src/emacs/highlight-parentheses/), so it's probably
related to your parentheses highlighting package. If you're interested
in debugging this (I have no idea what this overlay stuff does), I'm
attaching a minimal-ish test case (an expunged version of my
.newsrc.eld): use with

emacs -Q -l .emacs.d/lisp/highlight-parentheses.el fake-newsrc.el  -e
"highlight-parentheses-mode"

and then try to move through the repeated sexps with C-M-f. Probably
works with hl-sexp too. It's pretty baffling since only thing it does is
either add overlays or code protected by save-excursion.

fake-newsrc.el
Description: application/emacs-lisp