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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9324 in the body.
You can then email your comments to 9324 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Movement past end of screen causes weird jump
Date: Thu, 18 Aug 2011 22:48:07 +0200

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

This bug has been plaguing me for some time, but I was finally able to
create a minimal recipe.  I can't reproduce it with this test in the
terminal and I don't use emacs in the terminal much so I don't know if
it happens there.  It might also be specific to Mac OS X.

It seems (at least in this case) to be dependent on there being a
continued line at the top, and the line that should be moved to just off
the screen so that it would have to rescroll.  Anyway here is the data
that can be used to reproduce it from `emacs -Q`:

Create a buffer with the data and place your cursor after the
first block of elisp code (line 21).  Use C-x C-e to evaluate it
to get all the parameters set up (it will move to the next line),
then C-x C-e again which _should_ move to the end of the file.
However, it moves to the beginning of the current line, so that
repeating C-x C-e will jump back and forth between the beginning
and end of the line.  At least that's what happens to me
today :-) I'm running bzr revno 105479.


-- This is not part of the file --
208. look at docs for `mouse-autoselect-window' to see if there is a better value that I should be using
209. make scroll-bar inactive when full buffer in view
210. make isearch ignore diactritics by default (until one is used or something)
211. use `declare-function' to silence warnings in init.el
212. Change all key bindings to C-c C-f for compiling/linting/syntax checking, C-c C-d for debugging, and C-c C-v for viewing/running
213. Make `to-do' update an org file which contains all the todos
214. Make a `find-nearby' to find 2 things within several lines
215. Make `zap-up-to-char-but-not-including' a la `zap-to-char' (maybe on S-M-z ?)
216. Use `align-regexp' with args to create `align-words' and `align-strings'

-------------------------------------------------------

(progn (set-frame-parameter (selected-frame) 'height 47)
       (set-frame-parameter (selected-frame) 'width (/ 178 2))
       ;; (delete-other-windows)
       ;; (split-window-side-by-side)
       (goto-line 22)
       (recenter -22)
       (move-end-of-line 1)
       (emacs-lisp-mode)
       )
(forward-sexp)



(defadvice server-goto-line-column (after server-visit-region.tex
                                         (line-col)
                                         activate)
 "When visiting a file from an external source, make sure that we
are not narrowed, since the external source almost certainly
uses absolute file line numbers."
 (when (string-match "_region_.tex\\'" (buffer-file-name))
   (save-excursion ;; in case we don't find the other file we at least want the right line...
     (if (re-search-backward
          "\message{ !name(\\([^)]+\\))\\(?: !offset(\\([-0-9]+\\))\\)?\\s *}" nil nil)
         (let ((file-name (match-string 1))
               (offset (match-string 2))
               (line (car (ad-get-arg 0)))
               (col (cdr (ad-get-arg 0))))
           (if offset (setq line (+ line (string-to-number offset))))
           (find-file file-name nil)
           ;; Ironic, but I think cleaner then reimplementing...
           (server-goto-line-column (cons line col))
           (message "Moved from _region_.tex to line %s of %s." line file-name))

       ;; else
       (message "This is _region_.tex, but I couldn't find the original file!")))))
-- This is not part of the file --

The file should be 48 lines, 2275 bytes.



In GNU Emacs 24.0.50.1 (i386-apple-darwin10.8.0, NS apple-appkit-1038.36)
of 2011-08-17 on oroszlan.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  gd-enabled: t
  fold-mode-active: t
  TeX-PDF-mode: t
  highlight-parentheses-mode: t
  eldoc-mode: t
  hl-sexp-mode: t
  highlight-symbol-mode: t
  hi-lock-mode: t
  drag-stuff-global-mode: t
  drag-stuff-mode: t
  which-function-mode: t
  show-paren-mode: t
  recentf-mode: t
  msb-mode: t
  ido-everywhere: t
  global-hl-line-mode: t
  delete-selection-mode: t
  auto-image-file-mode: t
  auto-insert-mode: t
  yas/global-mode: t
  global-visible-mark-mode: t
  visible-mark-mode: t
  gvol-mode: t
  desktop-save-mode: t
  command-frequency-autosave-mode: t
  command-frequency-mode: t
  itunes-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<backspace> <backspace> <backspace> m a c s - l i s 
p = m <backspace> <backspace> - m o d e <tab> C-e C-x 
C-e C-k C-k <up> C-x C-e <C-up> <C-up> <C-up> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <up> <up> <up> <up> <up> C-e <left> <left> <backspace> 
<C-down> <up> C-x C-e C-x C-e C-e C-x C-e C-x C-e C-x 
C-e C-x C-e C-x C-e C-x C-e <C-up> <C-up> <C-up> <C-up> 
<C-up> C-x C-s C-x 1 <C-down> <C-down> <C-down> <up> 
C-x C-e C-x C-e C-x C-e C-x C-e C-x C-e TAB TAB TAB 
TAB TAB TAB C-; TAB C-; C-k C-k C-k C-k C-k C-k C-k 
TAB C-x C-e C-x C-e C-x 1 C-x C-e C-x C-e C-x C-e C-M-j 
C-M-j C-x 3 TAB TAB TAB TAB TAB TAB TAB TAB C-e C-u 
C-1 M-( / SPC C-M-l SPC 2 C-k C-k C-k C-k C-k C-k C-k 
C-x 1 C-x C-e C-x C-e C-x C-e C-x C-e C-x C-e C-x C-e 
C-x C-e C-x C-e C-x C-s <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
C-x C-r C-x C-r C-x C-r C-S-z C-S-z C-S-z C-S-z <down-mouse-1> 
<mouse-1> C-SPC 0 C-e C-x C-e C-j C-SPC 1 C-e C-x C-e 
C-j C-SPC 8 C-e C-x C-e C-j C-SPC 7 C-e C-M-o C-x C-e 
C-x C-e C-x C-e C-M-j C-M-j TAB TAB TAB TAB C-e C-k 
C-k C-k C-x C-e TAB TAB TAB TAB C-o C-o C-SPC 2 C-k 
C-k C-k C-x C-e C-x C-e C-x C-e C-x C-e C-x C-e <help-echo> 
<ns-toggle-toolbar> TAB C-x C-e C-x C-e C-x C-e C-x 
C-e C-e C-x C-e C-x C-e M-x r e p o <tab> r <tab> e 
m <tab> <return>

Recent messages:
nil [2 times]
Mark set
nil
Mark set
nil [2 times]
Mark set
nil [3 times]
Mark set
nil
Making completion list...

Load-path shadows:
None found.

Features:
(shadow message rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader emacsbug mail-utils url-cache timezone
parse-time network-stream starttls url-http tls mail-parse rfc2231
rfc2047 rfc2045 ietf-drums url-gw url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-util url-parse
url-vars mailcap org-feed align reftex-sel reftex-parse reftex-cite
texmathp sgml-mode ibuf-ext ibuffer smerge-mode diff-mode epa-file epa
epg epg-config autorevert follow vc-dir ewoc mail-extr ffap sort repeat
tabify org-table calc-misc calc-menu calc-ext calc calc-loaddefs
calc-macs shell shell-toggle two-column elide-head vc-bzr find-func
apropos debug subword dabbrev multi-isearch latexenc newcomment
hideshow-org reftex-vcr reftex-dcr reftex-auc reftex reftex-vars preview
prv-emacs tex-fold tex-bar tex-buf toolbar-x font-latex latex tex-style
tex highlight-parentheses reveal org-habit org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp
ob-exp org-exp-blocks org-info org-gnus org-docview org-bibtex bibtex
org-bbdb org-agenda ob-python org ob-emacs-lisp ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint ob-keys ob ob-eval org-pcomplete
pcomplete org-list org-faces org-compat org-entities org-macs noutline
outline eldoc hl-sexp gvol-light-theme greedy-delete sage-mode
ansi-color hideshow python-21 python gap-mode gap-process
highlight-symbol thingatpt hi-lock drag-stuff vc-hg compile comint
sh-script executable applescript-mode-autoloads auctex-autoloads
tex-site info browse-kill-ring-autoloads columnify-autoloads
drag-stuff-autoloads highlight-parentheses-autoloads
highlight-symbol-autoloads speck-autoloads xml-rpc-autoloads package
tabulated-list saveplace uniquify jka-compr which-func imenu paren
recentf tree-widget wid-edit msb ido icomplete hl-line delsel image-file
cus-start cus-load diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs warnings autoinsert yasnippet dropdown-list derived edmacro
kmacro help-mode view tramp tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv macroexp gnus-util mm-util mail-prsvr
password-cache format-spec tramp-loaddefs visible-mark parenface fold cl
commit-patch-buffer log-edit ring pcvs-util add-log vc ediff
vc-dispatcher xml desktop backtr command-frequency uptimes pp server
easy-mmode assoc dired+ dired-x easymenu ediff-merg ediff-diff
ediff-wind ediff-mult ediff-help ediff-init ediff-util dired-aux dired
regexp-opt advice help-fns advice-preload windmove time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Thu, 18 Aug 2011 23:11:10 +0200

18/08/11 22:48, Ivan Andrus
> Please describe exactly what actions triggered the bug, and
> the precise symptoms of the bug.  If you can, give a recipe
> starting from `emacs -Q':
>
> This bug has been plaguing me for some time, but I was finally able to
> create a minimal recipe.  I can't reproduce it with this test in the
> terminal and I don't use emacs in the terminal much so I don't know if
> it happens there.  It might also be specific to Mac OS X.
>
> It seems (at least in this case) to be dependent on there being a
> continued line at the top, and the line that should be moved to just off
> the screen so that it would have to rescroll.  Anyway here is the data
> that can be used to reproduce it from `emacs -Q`:
>
> Create a buffer with the data and place your cursor after the
> first block of elisp code (line 21).  Use C-x C-e to evaluate it
> to get all the parameters set up (it will move to the next line),
> then C-x C-e again which _should_ move to the end of the file.
> However, it moves to the beginning of the current line, so that
> repeating C-x C-e will jump back and forth between the beginning
> and end of the line.  At least that's what happens to me
> today :-) I'm running bzr revno 105479.

Can't reproduce it here on emacs -Q. I do C-x C-e to evaluate the
(progn), it jumps to the end of the (forward-sexp) with view centred on
the (forward-sexp), and when I do the (forward-sexp), it jumps to the
end of the defadvice, as expected. That's emacs trunk, under linux, GTK
build.  Attaching a screenshot so you can see what it looks like:
http://imageshack.us/photo/my-images/27/screenshotemacslambda.png/

Message #11 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>,
	Antoine Levitt <antoine.levitt <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 11:25:55 +0300

> From: Antoine Levitt <antoine.levitt <at> gmail.com>
> Date: Thu, 18 Aug 2011 23:11:10 +0200
> 
> Can't reproduce it here on emacs -Q. I do C-x C-e to evaluate the
> (progn), it jumps to the end of the (forward-sexp) with view centred on
> the (forward-sexp), and when I do the (forward-sexp), it jumps to the
> end of the defadvice, as expected. That's emacs trunk, under linux, GTK
> build.

Same here with today's trunk on MS-Windows.

Ivan, what major mode is active in the buffer where you see the
problem?  I didn't tell that in your report.  I tried Fundamental mode
and Text mode, and couldn't see the problem with either one.

Also, what are the dimensions of your window, in character cell units?

Thanks.

Message #14 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, Antoine Levitt <antoine.levitt <at> gmail.com>
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 11:54:29 +0200

On Aug 19, 2011, at 10:25 AM, Eli Zaretskii wrote:
>> From: Antoine Levitt <antoine.levitt <at> gmail.com>
>> Date: Thu, 18 Aug 2011 23:11:10 +0200
>> 
>> Can't reproduce it here on emacs -Q. I do C-x C-e to evaluate the
>> (progn), it jumps to the end of the (forward-sexp) with view centred on
>> the (forward-sexp), and when I do the (forward-sexp), it jumps to the
>> end of the defadvice, as expected. That's emacs trunk, under linux, GTK
>> build.
> 
> Same here with today's trunk on MS-Windows.

Somehow I'm not surprised.  It's been an extremely fickle bug.  I suppose it must be Mac specific or more people would have noticed by now.

> Ivan, what major mode is active in the buffer where you see the
> problem?  I didn't tell that in your report.  I tried Fundamental mode
> and Text mode, and couldn't see the problem with either one.

The progn should set it to emacs-lisp-mode which is where I see the problem.  Text mode doesn't exhibit the problem, nor does fundamental mode.

> Also, what are the dimensions of your window, in character cell units?

I'm not sure exactly what you mean.  Is this it? 

(cons (window-width) (window-height))
(89 . 46)

I have included the output from (frame-parameters (selected-frame)) in case that helps as well.  I just noticed that the frame height and window height don't match.  Is that normal?  

If there is anything else I can do to debug it I would be happy, it's just that I have no clue where to begin.  It's not (entirely) due to the actual movement command since running `forward-paragraph' also demonstrates the problem, though curiously `end-of-buffer' works fine. But end-of-buffer sends point to a different line than either of `forward-paragraph' and `forward-sexp'.

-Ivan

((tool-bar-position . top)
 (parent-id)
 (explicit-name)
 (display . "oroszlan.local")
 (visibility . t)
 (icon-name)
 (window-id . "3")
 (top . 22)
 (left . 23)
 (buried-buffer-list)
 (buffer-list #<buffer *temp buffer 1734232700394664397*> #<buffer *Apropos*> #<buffer  *Minibuf-1*> #<buffer  *Minibuf-2*> #<buffer *Occur*>)
 (unsplittable)
 (minibuffer . #<window 159 on  *Minibuf-1*>)
 (modeline . t)
 (width . 89)
 (height . 47)
 (name . "*temp buffer 1734232700394664397*")
 (cursor-color . "black")
 (scroll-bar-background . "grey75")
 (background-mode . light)
 (display-type . color)
 (alpha 93 63)
 (scroll-bar-width . 0)
 (cursor-type . box)
 (auto-lower)
 (auto-raise)
 (icon-type)
 (title)
 (buffer-predicate)
 (tool-bar-lines . 0)
 (menu-bar-lines . 1)
 (right-fringe . 11)
 (left-fringe . 10)
 (line-spacing)
 (background-color . "gray95")
 (foreground-color . "black")
 (vertical-scroll-bars)
 (internal-border-width . 2)
 (border-width . 0)
 (font . "-apple-Monaco-medium-normal-normal-*-12-*-*-*-m-0-iso10646-1")
 (fontsize . 0)
 (font-backend ns))

Message #17 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, Antoine Levitt <antoine.levitt <at> gmail.com>
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 12:02:58 +0200

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

Of course I could be completely wrong about that. :-)

-Ivan

Message #20 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 13:41:56 +0300

> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Fri, 19 Aug 2011 12:02:58 +0200
> Cc: Antoine Levitt <antoine.levitt <at> gmail.com>,
>  9324 <at> 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?

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

Message #23 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 18:19:47 +0200

On Aug 19, 2011, at 12:41 PM, Eli Zaretskii wrote:
>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Fri, 19 Aug 2011 12:02:58 +0200
>> Cc: Antoine Levitt <antoine.levitt <at> gmail.com>,
>> 9324 <at> 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.

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?

Thanks,
Ivan

Message #26 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9324 <at> debbugs.gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 18:51:21 +0200

[Message part 1 (text/plain, inline)]

19/08/11 18:19, Ivan Andrus
> On Aug 19, 2011, at 12:41 PM, Eli Zaretskii wrote:
>>> From: Ivan Andrus <darthandrus <at> gmail.com>
>>> Date: Fri, 19 Aug 2011 12:02:58 +0200
>>> Cc: Antoine Levitt <antoine.levitt <at> gmail.com>,
>>> 9324 <at> 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 (application/emacs-lisp, attachment)]

Message #29 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 20:15:19 +0300

> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Fri, 19 Aug 2011 18:19:47 +0200
> Cc: antoine.levitt <at> gmail.com,
>  9324 <at> debbugs.gnu.org
> 
> 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).

If invoking `redisplay' fixes the problem, it means some display
optimization is misfiring.  But there are quite a few of those
optimizations, so without a reproducible test case, it's really hard
to say where to look.

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

I agree with Antoine: if you can reliably reproduce this with your
~/..emacs, bisect it to find the minimal customizations necessary to
reproduce the problem, then post that information here.

Message #32 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 20:38:09 +0200

[Message part 1 (text/plain, inline)]

On Aug 19, 2011, at 7:15 PM, Eli Zaretskii wrote:

>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Fri, 19 Aug 2011 18:19:47 +0200
>> Cc: antoine.levitt <at> gmail.com,
>> 9324 <at> debbugs.gnu.org
>> 
>> 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).
> 
> If invoking `redisplay' fixes the problem, it means some display
> optimization is misfiring.  But there are quite a few of those
> optimizations, so without a reproducible test case, it's really hard
> to say where to look.
> 
>> 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?
> 
> I agree with Antoine: if you can reliably reproduce this with your
> ~/..emacs, bisect it to find the minimal customizations necessary to
> reproduce the problem, then post that information here.

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

Thanks for your patience and pointers,
Ivan

[bug-example-3.el (application/octet-stream, attachment)]

Message #35 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 19 Aug 2011 22:06:51 +0300

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

Message #38 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Sat, 20 Aug 2011 09:33:31 +0200

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

Message #41 received at 9324 <at> debbugs.gnu.org (full text, mbox):

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

Message #44 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324 <at> debbugs.gnu.org
Subject: Re: 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.

Message #47 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Andrus <darthandrus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9324 <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Thu, 25 Aug 2011 22:11:37 +0200

[Message part 1 (text/plain, inline)]

I tried to build it with GTK, but it segfaulted, so I can't tell if it works there or not.  I was _____ able to reproduce it with the athena toolkit.

On Aug 20, 2011, at 1:29 PM, Eli Zaretskii wrote:
>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Sat, 20 Aug 2011 09:33:31 +0200
>> Cc: antoine.levitt <at> gmail.com,
>> 9324 <at> 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.

Indeed and that is very important to reproducing this bug.  What is your frame size?  Actually when building with athena I couldn't get the frame big enough, so I changed the test case a little.  At the end of the day what seems important is that the first line showing be a continuation line.  Then executing the (forward-sexp) gives the buggy behavior.

> What is the value of `lpoint' after line 14682?  

NB: the line numbers have changed slightly, but these represent values after the appropriate SET_TEXT_POS etc.

(gdb) p lpoint
$1 = {
  charpos = 2461, 
  bytepos = 2461
}

> What is the value of
> `opoint' after line 14764?  

(gdb) p opoint
$2 = {
  charpos = 2461, 
  bytepos = 2461
}

> And what is the value of `startp' at line
> 14886?

(gdb) p startp
$3 = {
  charpos = 90, 
  bytepos = 90
}

This was using revision 105563, configured with
CFLAGS='-ggdb -g3' ./configure --with-x-toolkit=athena     --with-gif=no
and using a slightly different file than before (which I have attached) and debugging with

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

Then breaking on redisplay_window and evaluating the progn block (I had to scroll to avoid a beginning of buffer error that I thought unwind-protect would take care of but didn't) and then the forward-sexp block.
I didn't even need to evaluate the mode-line change this time, probably due to the way that I ensure the first line is a continuation line.

Anyway, I hope that makes sense and helps.  If you need any other debugging output I would be happy, either in the NextStep version or the athena version (or both).

-Ivan

[bug-example-3.el (application/octet-stream, attachment)]

Message #50 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9324 <at> debbugs.gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Thu, 25 Aug 2011 22:59:30 +0200

25/08/11 22:11, Ivan Andrus
> I tried to build it with GTK, but it segfaulted, so I can't tell if it
> works there or not.  I was _____ able to reproduce it with the athena
> toolkit.

If that helps, see my previous post, with a recipe to reproduce it under
GTK with only highlight-parentheses. I tried with rev 105567, whose
commit message made it look like it was about this bug, still no luck.

Message #55 received at 9324-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Andrus <darthandrus <at> gmail.com>
Cc: 9324-done <at> debbugs.gnu.org, antoine.levitt <at> gmail.com
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 26 Aug 2011 13:20:17 +0300

> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Thu, 25 Aug 2011 22:11:37 +0200
> Cc: antoine.levitt <at> gmail.com,
>  9324 <at> debbugs.gnu.org
> 
> Indeed and that is very important to reproducing this bug.  What is your frame size?  Actually when building with athena I couldn't get the frame big enough, so I changed the test case a little.  At the end of the day what seems important is that the first line showing be a continuation line.  Then executing the (forward-sexp) gives the buggy behavior.

I've managed to reproduce this.  Please note that most of the `progn'
in bug-example-3.el is just clutter and is not needed to see the
problem (that clutter is part of the reason why it took so long to see
the problem).  Frame dimensions, mode-line face, exactly how you
scroll and recenter -- all these are irrelevant.  All you need is
this:

  emacs -Q -l highlight-parentheses.el -l hl-sexp.el bug-example-3.el
  C-u 1 C-v
  M-x goto-line RET 24 RET
  M-x hl-sexp-mode RET
  M-x highlight-parentheses-mode RET
  C-M-f

After this, Emacs moves point to be centered in the window, instead of
scrolling the window to show point at the end of the buffer, after the
sexp it was supposed to move across as result of C-M-f.

I fixed this in revision 105577 on the trunk.

Message #58 received at 9324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Antoine Levitt <antoine.levitt <at> gmail.com>
Cc: darthandrus <at> gmail.com, 9324 <at> debbugs.gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 26 Aug 2011 13:32:09 +0300

> From: Antoine Levitt <antoine.levitt <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  9324 <at> debbugs.gnu.org
> Date: Thu, 25 Aug 2011 22:59:30 +0200
> 
> If that helps, see my previous post, with a recipe to reproduce it under
> GTK with only highlight-parentheses.

I needed both highlight-parentheses and hl-sexp to reproduce the
problem.  Either one of them alone didn't.

> I tried with rev 105567, whose commit message made it look like it
> was about this bug, still no luck.

Revision 105567 was not relevant because it handled a problem specific
to the bidi display.  By contrast, this problem happens even with
bidi-display-reordering turned off, and in fact is present in Emacs 23
as well.

Message #59 received at 9324-done <at> debbugs.gnu.org (full text, mbox):

From: Antoine Levitt <antoine.levitt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ivan Andrus <darthandrus <at> gmail.com>, 9324-done <at> debbugs.gnu.org
Subject: Re: bug#9324: 24.0.50; Movement past end of screen causes weird jump
Date: Fri, 26 Aug 2011 16:04:02 +0200

26/08/11 12:20, Eli Zaretskii
>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Thu, 25 Aug 2011 22:11:37 +0200
>> Cc: antoine.levitt <at> gmail.com,
>>  9324 <at> debbugs.gnu.org
>> 
>> Indeed and that is very important to reproducing this bug.  What is
>> your frame size?  Actually when building with athena I couldn't get
>> the frame big enough, so I changed the test case a little.  At the
>> end of the day what seems important is that the first line showing
>> be a continuation line.  Then executing the (forward-sexp) gives the
>> buggy behavior.
>
> I've managed to reproduce this.  Please note that most of the `progn'
> in bug-example-3.el is just clutter and is not needed to see the
> problem (that clutter is part of the reason why it took so long to see
> the problem).  Frame dimensions, mode-line face, exactly how you
> scroll and recenter -- all these are irrelevant.  All you need is
> this:
>
>   emacs -Q -l highlight-parentheses.el -l hl-sexp.el bug-example-3.el
>   C-u 1 C-v
>   M-x goto-line RET 24 RET
>   M-x hl-sexp-mode RET
>   M-x highlight-parentheses-mode RET
>   C-M-f
>
> After this, Emacs moves point to be centered in the window, instead of
> scrolling the window to show point at the end of the buffer, after the
> sexp it was supposed to move across as result of C-M-f.
>
> I fixed this in revision 105577 on the trunk.

Confirmed, thanks!

Previous Next

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