* bug#9324: 24.0.50; Movement past end of screen causes weird jump @ 2011-08-18 20:48 Ivan Andrus 2011-08-18 21:11 ` Antoine Levitt 0 siblings, 1 reply; 18+ messages in thread From: Ivan Andrus @ 2011-08-18 20:48 UTC (permalink / raw) To: 9324 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-18 20:48 bug#9324: 24.0.50; Movement past end of screen causes weird jump Ivan Andrus @ 2011-08-18 21:11 ` Antoine Levitt 2011-08-19 8:25 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Antoine Levitt @ 2011-08-18 21:11 UTC (permalink / raw) To: 9324 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-18 21:11 ` Antoine Levitt @ 2011-08-19 8:25 ` Eli Zaretskii 2011-08-19 9:54 ` Ivan Andrus 2011-08-19 10:02 ` Ivan Andrus 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2011-08-19 8:25 UTC (permalink / raw) To: Ivan Andrus, Antoine Levitt; +Cc: 9324 > From: Antoine Levitt <antoine.levitt@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 8:25 ` Eli Zaretskii @ 2011-08-19 9:54 ` Ivan Andrus 2011-08-19 10:02 ` Ivan Andrus 1 sibling, 0 replies; 18+ messages in thread From: Ivan Andrus @ 2011-08-19 9:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, Antoine Levitt On Aug 19, 2011, at 10:25 AM, Eli Zaretskii wrote: >> From: Antoine Levitt <antoine.levitt@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)) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 8:25 ` Eli Zaretskii 2011-08-19 9:54 ` Ivan Andrus @ 2011-08-19 10:02 ` Ivan Andrus 2011-08-19 10:41 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Ivan Andrus @ 2011-08-19 10:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, Antoine Levitt 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 10:02 ` Ivan Andrus @ 2011-08-19 10:41 ` Eli Zaretskii 2011-08-19 16:19 ` Ivan Andrus 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2011-08-19 10:41 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324, antoine.levitt > 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? > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 10:41 ` Eli Zaretskii @ 2011-08-19 16:19 ` Ivan Andrus 2011-08-19 16:51 ` Antoine Levitt 2011-08-19 17:15 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Ivan Andrus @ 2011-08-19 16:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, antoine.levitt 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. 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 16:19 ` Ivan Andrus @ 2011-08-19 16:51 ` Antoine Levitt 2011-08-19 17:15 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Antoine Levitt @ 2011-08-19 16:51 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324 [-- Attachment #1: Type: text/plain, Size: 3217 bytes --] 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. [-- Attachment #2: fake-newsrc.el --] [-- Type: application/emacs-lisp, Size: 4686 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 16:19 ` Ivan Andrus 2011-08-19 16:51 ` Antoine Levitt @ 2011-08-19 17:15 ` Eli Zaretskii 2011-08-19 18:38 ` Ivan Andrus 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2011-08-19 17:15 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324, antoine.levitt > From: Ivan Andrus <darthandrus@gmail.com> > Date: Fri, 19 Aug 2011 18:19:47 +0200 > Cc: antoine.levitt@gmail.com, > 9324@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 17:15 ` Eli Zaretskii @ 2011-08-19 18:38 ` Ivan Andrus 2011-08-19 19:06 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Ivan Andrus @ 2011-08-19 18:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, antoine.levitt [-- Attachment #1: Type: text/plain, Size: 1587 bytes --] On Aug 19, 2011, at 7:15 PM, Eli Zaretskii wrote: >> From: Ivan Andrus <darthandrus@gmail.com> >> Date: Fri, 19 Aug 2011 18:19:47 +0200 >> Cc: antoine.levitt@gmail.com, >> 9324@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 [-- Attachment #2: bug-example-3.el --] [-- Type: application/octet-stream, Size: 2418 bytes --] 208. look at docs for `mouse-autoselect-window' to see if there is a better value that I should be using 209. Look at occur (C-h f occur RET) to see how to make a nice menu buffer, thing-amagig 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' ------------------------------------------------------- (custom-set-faces '(mode-line ((t (:box (:line-width 1)))))) (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) (highlight-parentheses-mode 1) (hl-sexp-mode 1) ) (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!"))))) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 18:38 ` Ivan Andrus @ 2011-08-19 19:06 ` Eli Zaretskii 2011-08-20 7:33 ` Ivan Andrus 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2011-08-19 19:06 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324, antoine.levitt > From: Ivan Andrus <darthandrus@gmail.com> > Date: Fri, 19 Aug 2011 20:38:09 +0200 > Cc: antoine.levitt@gmail.com, > 9324@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-19 19:06 ` Eli Zaretskii @ 2011-08-20 7:33 ` Ivan Andrus 2011-08-20 11:29 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Ivan Andrus @ 2011-08-20 7:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, antoine.levitt On Aug 19, 2011, at 9:06 PM, Eli Zaretskii wrote: >> From: Ivan Andrus <darthandrus@gmail.com> >> Date: Fri, 19 Aug 2011 20:38:09 +0200 >> Cc: antoine.levitt@gmail.com, >> 9324@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-20 7:33 ` Ivan Andrus @ 2011-08-20 11:29 ` Eli Zaretskii [not found] ` <0760243C-31D8-492E-99BE-86D87D7601F6@gmail.com> 2011-08-25 20:11 ` Ivan Andrus 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2011-08-20 11:29 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324, antoine.levitt > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <0760243C-31D8-492E-99BE-86D87D7601F6@gmail.com>]
* bug#9324: 24.0.50; Movement past end of screen causes weird jump [not found] ` <0760243C-31D8-492E-99BE-86D87D7601F6@gmail.com> @ 2011-08-20 14:37 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2011-08-20 14:37 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324 > From: Ivan Andrus <darthandrus@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-20 11:29 ` Eli Zaretskii [not found] ` <0760243C-31D8-492E-99BE-86D87D7601F6@gmail.com> @ 2011-08-25 20:11 ` Ivan Andrus 2011-08-25 20:59 ` Antoine Levitt 2011-08-26 10:20 ` Eli Zaretskii 1 sibling, 2 replies; 18+ messages in thread From: Ivan Andrus @ 2011-08-25 20:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9324, antoine.levitt [-- Attachment #1: Type: text/plain, Size: 2874 bytes --] 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@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. 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 [-- Attachment #2: bug-example-3.el --] [-- Type: application/octet-stream, Size: 2461 bytes --] 208. look at docs for `mouse-autoselect-window' to see if there is a better value that I should be using 209. Look at occur (C-h f occur RET) to see how to make a nice menu buffer, thing-amagig 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' ------------------------------------------------------- (custom-set-faces '(mode-line ((t (:box (:line-width 1)))))) (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) (unwind-protect (scroll-down)) (scroll-up 1) ;(recenter -22) (move-end-of-line 1) (emacs-lisp-mode) (highlight-parentheses-mode 1) (hl-sexp-mode 1) ) (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!"))))) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-25 20:11 ` Ivan Andrus @ 2011-08-25 20:59 ` Antoine Levitt 2011-08-26 10:32 ` Eli Zaretskii 2011-08-26 10:20 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Antoine Levitt @ 2011-08-25 20:59 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-25 20:59 ` Antoine Levitt @ 2011-08-26 10:32 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2011-08-26 10:32 UTC (permalink / raw) To: Antoine Levitt; +Cc: darthandrus, 9324 > From: Antoine Levitt <antoine.levitt@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 9324@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9324: 24.0.50; Movement past end of screen causes weird jump 2011-08-25 20:11 ` Ivan Andrus 2011-08-25 20:59 ` Antoine Levitt @ 2011-08-26 10:20 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2011-08-26 10:20 UTC (permalink / raw) To: Ivan Andrus; +Cc: 9324-done, antoine.levitt > From: Ivan Andrus <darthandrus@gmail.com> > Date: Thu, 25 Aug 2011 22:11:37 +0200 > Cc: antoine.levitt@gmail.com, > 9324@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-08-26 10:32 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-08-18 20:48 bug#9324: 24.0.50; Movement past end of screen causes weird jump Ivan Andrus 2011-08-18 21:11 ` Antoine Levitt 2011-08-19 8:25 ` Eli Zaretskii 2011-08-19 9:54 ` Ivan Andrus 2011-08-19 10:02 ` Ivan Andrus 2011-08-19 10:41 ` Eli Zaretskii 2011-08-19 16:19 ` Ivan Andrus 2011-08-19 16:51 ` Antoine Levitt 2011-08-19 17:15 ` Eli Zaretskii 2011-08-19 18:38 ` Ivan Andrus 2011-08-19 19:06 ` Eli Zaretskii 2011-08-20 7:33 ` Ivan Andrus 2011-08-20 11:29 ` Eli Zaretskii [not found] ` <0760243C-31D8-492E-99BE-86D87D7601F6@gmail.com> 2011-08-20 14:37 ` Eli Zaretskii 2011-08-25 20:11 ` Ivan Andrus 2011-08-25 20:59 ` Antoine Levitt 2011-08-26 10:32 ` Eli Zaretskii 2011-08-26 10:20 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.