* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk @ 2013-11-22 22:23 Anders Lindgren 2013-11-23 11:58 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Anders Lindgren @ 2013-11-22 22:23 UTC (permalink / raw To: 15957 [-- Attachment #1: Type: text/plain, Size: 2976 bytes --] Hi! Scrolling multiple pages when Follow mode is enabled sometimes fails. Steps to repeat: Emacs -Q C-h t ESC : (set-frame-size (selected-frame) 200 70) RET M-x follow-delete-other-windows-and-split RET C-c . C-v The intent is to scroll the entire document two pages down, the left window should still be selected (this causes Follow mode to arrange the right window after it). Instead, the right window is selected, which causes the left to be arranged after it, effectively undoing the scroll. The problem seems to be sometimes intermittent, sometimes the scroll works, sometimes it don't. An interesting effect is that the problem only occurs when follow-scroll-up is bound to a key. When issuing M-x follow-scroll-up RET, the command seems to be working properly. By the way, I'm the original author of Follow mode, even tough I haven't touched it for many years. Sincerely, Anders Lindgren In GNU Emacs 24.3.50.11 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00) of 2013-11-21 on macpro.lan Bzr revision: 115156 rgm@gnu.org-20131120081620-w7c04v1rspm8i0dr Windowing system distributor `Apple', version 10.3.1265 Configured using: `configure --with-ns' Important settings: value of $LC_CTYPE: UTF-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: follow-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 blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <help-echo> C-x C-g C-h t x C-x u <escape> x f o l l o w - d e <tab> <return> C-c . C-v <escape> x r e p o r t - b <tab> <return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. C-x C-g is undefined Preparing tutorial ... Undo! Load-path shadows: None found. Features: (shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils follow tutorial help-mode easymenu time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-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 nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process cocoa ns multi-tty emacs) [-- Attachment #2: Type: text/html, Size: 4084 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-22 22:23 bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk Anders Lindgren @ 2013-11-23 11:58 ` martin rudalics 2013-11-23 22:01 ` Anders Lindgren 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-23 11:58 UTC (permalink / raw To: Anders Lindgren; +Cc: 15957 Hi Anders > Scrolling multiple pages when Follow mode is enabled sometimes fails. > > Steps to repeat: > > Emacs -Q > C-h t > ESC : (set-frame-size (selected-frame) 200 70) RET Is this really necessary? 70 lines means I can't see my echo area any more. > M-x follow-delete-other-windows-and-split RET > C-c . C-v > > The intent is to scroll the entire document two pages down, the left > window should still be selected (this causes Follow mode to arrange the > right window after it). Instead, the right window is selected, Can you tell when and where the window on the right is selected? > which causes > the left to be arranged after it, effectively undoing the scroll. IIUC `follow-scroll-up' should select the proper window via (let* ((windows (follow-all-followers)) (end (window-end (car (reverse windows))))) (if (eq end (point-max)) (signal 'end-of-buffer nil) (select-window (car windows)) which seems to imply that `follow-all-followers' doesn't return what it is supposed to. Am I correct that the first window returned by the latter should be `frame-first-window'? In that case try to replace the last line of `follow-all-followers' by something like (prog1 (setq windows (sort windows 'follow--window-sorter)) (unless (eq (car windows) (frame-first-window (window-frame win))) (error "Bad windows %s" windows))))) and maybe this way we can find out whether the problem is there. > The problem seems to be sometimes intermittent, sometimes the scroll works, > sometimes it don't. > > An interesting effect is that the problem only occurs when > follow-scroll-up is bound to a key. When issuing M-x follow-scroll-up > RET, the command seems to be working properly. I have no idea why this could change the course of things because ARG should be nil in both cases. > By the way, I'm the original author of Follow mode, even tough I haven't > touched it for many years. I suppose you should touch it again ;-) martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-23 11:58 ` martin rudalics @ 2013-11-23 22:01 ` Anders Lindgren 2013-11-24 10:10 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Anders Lindgren @ 2013-11-23 22:01 UTC (permalink / raw To: martin rudalics; +Cc: 15957 [-- Attachment #1: Type: text/plain, Size: 3233 bytes --] Hi! No, the actual numbers don't appear to be important. I simply picked some numbers to make sure the frame was wide enough for two side-by-side windows. I tried 40 instead of 70 and you get the same effect. I really doubt that the code in `follow-scroll-up' is broken. Follow-mode is designed so that the rearrangement of the other windows (the ones that follow the selected window) occur in the post-command hook (to allow Follow-mode to act upon all Emacs commands, not only it's special function). It appears that something has changed in the display engine, or in the way that post-command-hook is called, that makes this mechanism fail. This could also account for the difference we see when the function is called via a key sequence as compared to via M-x. This is also the reason why reported this as a bug, rather than digging into the code myself. However, I could try to add log code to Follow mode, to check if I could try to figure out what is going on. -- Anders On Sat, Nov 23, 2013 at 12:58 PM, martin rudalics <rudalics@gmx.at> wrote: > Hi Anders > > > Scrolling multiple pages when Follow mode is enabled sometimes fails. > > > > Steps to repeat: > > > > Emacs -Q > > C-h t > > ESC : (set-frame-size (selected-frame) 200 70) RET > > Is this really necessary? 70 lines means I can't see my echo area any > more. > > > M-x follow-delete-other-windows-and-split RET > > C-c . C-v > > > > The intent is to scroll the entire document two pages down, the left > > window should still be selected (this causes Follow mode to arrange the > > right window after it). Instead, the right window is selected, > > Can you tell when and where the window on the right is selected? > > > which causes > > the left to be arranged after it, effectively undoing the scroll. > > IIUC `follow-scroll-up' should select the proper window via > > (let* ((windows (follow-all-followers)) > (end (window-end (car (reverse windows))))) > (if (eq end (point-max)) > (signal 'end-of-buffer nil) > (select-window (car windows)) > > which seems to imply that `follow-all-followers' doesn't return what it > is supposed to. Am I correct that the first window returned by the > latter should be `frame-first-window'? In that case try to replace the > last line of `follow-all-followers' by something like > > (prog1 > (setq windows (sort windows 'follow--window-sorter)) > (unless (eq (car windows) (frame-first-window (window-frame win))) > (error "Bad windows %s" windows))))) > > and maybe this way we can find out whether the problem is there. > > > The problem seems to be sometimes intermittent, sometimes the scroll > works, > > sometimes it don't. > > > > An interesting effect is that the problem only occurs when > > follow-scroll-up is bound to a key. When issuing M-x follow-scroll-up > > RET, the command seems to be working properly. > > I have no idea why this could change the course of things because ARG > should be nil in both cases. > > > By the way, I'm the original author of Follow mode, even tough I haven't > > touched it for many years. > > I suppose you should touch it again ;-) > > martin > [-- Attachment #2: Type: text/html, Size: 4065 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-23 22:01 ` Anders Lindgren @ 2013-11-24 10:10 ` martin rudalics 2013-11-25 9:19 ` Anders Lindgren 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-24 10:10 UTC (permalink / raw To: Anders Lindgren; +Cc: 15957 > I really doubt that the code in `follow-scroll-up' is broken. I didn't say so. > Follow-mode > is designed so that the rearrangement of the other windows (the ones that > follow the selected window) occur in the post-command hook (to allow > Follow-mode to act upon all Emacs commands, not only it's special > function). It appears that something has changed in the display engine, or > in the way that post-command-hook is called, that makes this mechanism > fail. This could also account for the difference we see when the function > is called via a key sequence as compared to via M-x. IIUC we'd have to find out when and where follow-mode expects the selected window to be a certain window and why this sometimes fails. So maybe you should try the change I suggested. > This is also the reason why reported this as a bug, rather than digging > into the code myself. However, I could try to add log code to Follow mode, > to check if I could try to figure out what is going on. Please do that. Thanks, martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-24 10:10 ` martin rudalics @ 2013-11-25 9:19 ` Anders Lindgren [not found] ` <CABr8ebbnxDgVF-+pdk955Ux-SQuZDONw=OhHOVUdO9d=xsTcZg@mail.gmail.com> 0 siblings, 1 reply; 15+ messages in thread From: Anders Lindgren @ 2013-11-25 9:19 UTC (permalink / raw To: martin rudalics; +Cc: 15957 [-- Attachment #1: Type: text/plain, Size: 2517 bytes --] Hi! I tried something similar to the code you suggested. The code I tried checked both `follow-scroll-up' and `follow-post-command-hook'. It appears as though the selected window is changed somewhere in the post-command hook. This, however, does not occur when I call the post-command hook as a plain function. Also, I noticed that an old Emacs trunk I had laying around worked correctly, so I have spent some time to do a binary search of the bzr archive and found out that this broke in revision 113753, with the following log message: revno: 113753 committer: Dmitry Antipov <dmantipov@yandex.ru> branch nick: trunk timestamp: Thu 2013-08-08 08:42:40 +0400 message: Do not reset window modification event counters excessively. These leftovers and poor man's tricky methods to catch extra redisplay's attention are no longer needed. * frame.c (set_menu_bar_lines_1): * minibuf.c (read_minibuf_unwind): * window.c (Fset_window_start, set_window_buffer, window_resize_apply) (grow_mini_window, shrink_mini_window, window_scroll_pixel_based) (window_scroll_line_based, Fset_window_configuration): * xdisp.c (redisplay_window): Do not reset last_modified and last_overlay_modified counters. I will continue to narrow down the problem in the post-command hook, I'll let you know when I'm done. Sincerely, Anders Lindgren On Sun, Nov 24, 2013 at 11:10 AM, martin rudalics <rudalics@gmx.at> wrote: > > I really doubt that the code in `follow-scroll-up' is broken. > > I didn't say so. > > > > Follow-mode > > is designed so that the rearrangement of the other windows (the ones that > > follow the selected window) occur in the post-command hook (to allow > > Follow-mode to act upon all Emacs commands, not only it's special > > function). It appears that something has changed in the display engine, > or > > in the way that post-command-hook is called, that makes this mechanism > > fail. This could also account for the difference we see when the function > > is called via a key sequence as compared to via M-x. > > IIUC we'd have to find out when and where follow-mode expects the > selected window to be a certain window and why this sometimes fails. So > maybe you should try the change I suggested. > > > > This is also the reason why reported this as a bug, rather than digging > > into the code myself. However, I could try to add log code to Follow > mode, > > to check if I could try to figure out what is going on. > > Please do that. > > Thanks, martin > [-- Attachment #2: Type: text/html, Size: 3501 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CABr8ebbnxDgVF-+pdk955Ux-SQuZDONw=OhHOVUdO9d=xsTcZg@mail.gmail.com>]
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk [not found] ` <CABr8ebbnxDgVF-+pdk955Ux-SQuZDONw=OhHOVUdO9d=xsTcZg@mail.gmail.com> @ 2013-11-25 16:42 ` martin rudalics 2013-11-26 6:33 ` Dmitry Antipov 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-25 16:42 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957 Forwarding Anders Lindgren's mail to 15957@debbugs.gnu.org and Dmitry Antipov. > Hi! > > I believe that I have found the problem. In `follow-calc-win-end', there is > a call to `(window-end win t)'. The `t' means "compute the up-to-date > position > if it isn't already recorded." The return value from this function is > clearly incorrect. The fact that the wrong window is selected is simply a > consequence of this. > > In the older Emacs (up to bzr revision 113752), this seems to work > correctly. However, in the newer (starting from bzt revision 113753) this > is broken. > > You can verify this using the (somewhat crude) package I've attached below. > It adds logging to some Follow mode functions that triggers when you run a > special variant of the scroll command, which it binds to Ctrl-z. Once the > command has been executed, you can view the result by invoking > `check-follow-report-log'. > > As `window-end' is part of the display engine, which I have no knowledge > about, I hand it over to you to address the problem. > > Sincerely, > Anders Lindgren > > Ps. Below is the logs which I have recorded. > > Revision 113752: > > (Start #<window 0x109071050 on check-follow-scroll-bug.el>) > (Start (inside w-c-b) #<window 0x109071050 on check-follow-scroll-bug.el>) > (follow-calc-win-end #<window 0x109071050 on check-follow-scroll-bug.el>) > ( edges #<window 0x109071050 on check-follow-scroll-bug.el> (12 2 747 450)) > ( ht #<window 0x109071050 on check-follow-scroll-bug.el> 448) > ( last-line-pos #<window 0x109071050 on check-follow-scroll-bug.el> 3594) > ( Pos visible #<window 0x109071050 on check-follow-scroll-bug.el>) > ( end #<window 0x109071050 on check-follow-scroll-bug.el> 3632) > <------- Correct > ... > > Revision 113753: > > (Start #<window 0x10601ac08 on check-follow-scroll-bug.el>) > (Start (inside w-c-b) #<window 0x10601ac08 on check-follow-scroll-bug.el>) > (follow-calc-win-end #<window 0x10601ac08 on check-follow-scroll-bug.el>) > ( edges #<window 0x10601ac08 on check-follow-scroll-bug.el> (12 2 726 450)) > ( ht #<window 0x10601ac08 on check-follow-scroll-bug.el> 448) > ( last-line-pos #<window 0x10601ac08 on check-follow-scroll-bug.el> 3594) > ( Pos visible #<window 0x10601ac08 on check-follow-scroll-bug.el>) > ( end #<window 0x10601ac08 on check-follow-scroll-bug.el> 873) > <-------- Incorrect > > > > > > On Mon, Nov 25, 2013 at 10:19 AM, Anders Lindgren <andlind@gmail.com> wrote: > >> Hi! >> >> I tried something similar to the code you suggested. The code I tried >> checked both `follow-scroll-up' and `follow-post-command-hook'. It appears >> as though the selected window is changed somewhere in the post-command >> hook. This, however, does not occur when I call the post-command hook as a >> plain function. >> >> Also, I noticed that an old Emacs trunk I had laying around worked >> correctly, so I have spent some time to do a binary search of the bzr >> archive and found out that this broke in revision 113753, with the >> following log message: >> >> revno: 113753 >> >> committer: Dmitry Antipov <dmantipov@yandex.ru> >> >> branch nick: trunk >> >> timestamp: Thu 2013-08-08 08:42:40 +0400 >> >> message: >> >> Do not reset window modification event counters excessively. >> >> These leftovers and poor man's tricky methods to catch extra >> >> redisplay's attention are no longer needed. >> >> * frame.c (set_menu_bar_lines_1): >> >> * minibuf.c (read_minibuf_unwind): >> >> * window.c (Fset_window_start, set_window_buffer, window_resize_apply) >> >> (grow_mini_window, shrink_mini_window, window_scroll_pixel_based) >> >> (window_scroll_line_based, Fset_window_configuration): >> >> * xdisp.c (redisplay_window): Do not reset last_modified and >> >> last_overlay_modified counters. >> >> >> I will continue to narrow down the problem in the post-command hook, I'll >> let you know when I'm done. >> >> >> Sincerely, >> >> Anders Lindgren >> >> >> >> >> On Sun, Nov 24, 2013 at 11:10 AM, martin rudalics <rudalics@gmx.at> wrote: >> >>>> I really doubt that the code in `follow-scroll-up' is broken. >>> I didn't say so. >>> >>> >>>> Follow-mode >>>> is designed so that the rearrangement of the other windows (the ones >>> that >>>> follow the selected window) occur in the post-command hook (to allow >>>> Follow-mode to act upon all Emacs commands, not only it's special >>>> function). It appears that something has changed in the display engine, >>> or >>>> in the way that post-command-hook is called, that makes this mechanism >>>> fail. This could also account for the difference we see when the >>> function >>>> is called via a key sequence as compared to via M-x. >>> IIUC we'd have to find out when and where follow-mode expects the >>> selected window to be a certain window and why this sometimes fails. So >>> maybe you should try the change I suggested. >>> >>> >>>> This is also the reason why reported this as a bug, rather than digging >>>> into the code myself. However, I could try to add log code to Follow >>> mode, >>>> to check if I could try to figure out what is going on. >>> Please do that. >>> >>> Thanks, martin >>> >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-25 16:42 ` martin rudalics @ 2013-11-26 6:33 ` Dmitry Antipov 2013-11-26 11:01 ` Anders Lindgren 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Antipov @ 2013-11-26 6:33 UTC (permalink / raw To: martin rudalics, Anders Lindgren; +Cc: 15957 On 11/25/2013 08:42 PM, martin rudalics wrote: > Forwarding Anders Lindgren's mail to 15957@debbugs.gnu.org and Dmitry Antipov. > >> Hi! >> >> I believe that I have found the problem. In `follow-calc-win-end', there is >> a call to `(window-end win t)'. The `t' means "compute the up-to-date >> position >> if it isn't already recorded." The return value from this function is >> clearly incorrect. The fact that the wrong window is selected is simply a >> consequence of this. >> >> In the older Emacs (up to bzr revision 113752), this seems to work >> correctly. However, in the newer (starting from bzt revision 113753) this >> is broken. Hm...I just add debug printf() at the end of Fwindow_end, and see an identical output for 24.3 and r115239 for this simple example: ./src/emacs -Q -font 6x10 -geometry 200x65 C-h t M-x follow-delete-other-windows-and-split C-c . C-v So if someone has a elisp code that clearly shows that window-end is broken, please attach it to this bug at least. Dmitry ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 6:33 ` Dmitry Antipov @ 2013-11-26 11:01 ` Anders Lindgren 2013-11-26 14:12 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Anders Lindgren @ 2013-11-26 11:01 UTC (permalink / raw To: Dmitry Antipov; +Cc: 15957 [-- Attachment #1.1: Type: text/plain, Size: 2769 bytes --] Hi Dmitry! The problem only occurs under certain circumstances. `window-end' must called from a post-command hook and the command that started it must be bound to a key (not using M-x). Also, sometimes it seems to work correctly, sometimes not, like every second time. (Take "must" with a grain of salt, it might be possible to trigger the bug under other circumstances as well.) I have attached a piece of lisp code which basically is the follow-mode code plus log commands, so that you clearly can see the return value of different functions, including the call to `windows-end'. I'm sure it would be possible to cut down the code to a minimal, now when we know that it's `window-end' that returns the incorrect value. (The logs I referred to in the previous mails were generated by this package.) I'm not familiar with the bug tracking system, but feel free to add this code to it. In case you are not familiar with follow-mode, it is a package that creates the illusion that you have one large window spread out over several side-by-side windows, you can move between the windows using the normal cursor keys, and when you scroll one window, the others follow (hence the name "Follow mode"). Technically, this is accomplished by a using a post-command hook that performs all the repositioning, plus a handful of new function performing operations that didn't exist before (like scrolling X pages, where X equal the number of windows the buffer is shown in). Do you think that you have everything that you need to find and fix the bug, or is there anything else that I can help you with? Sincerely, Anders Lindgren On Tue, Nov 26, 2013 at 7:33 AM, Dmitry Antipov <dmantipov@yandex.ru> wrote: > On 11/25/2013 08:42 PM, martin rudalics wrote: > >> Forwarding Anders Lindgren's mail to 15957@debbugs.gnu.org and Dmitry >> Antipov. >> >> Hi! >>> >>> I believe that I have found the problem. In `follow-calc-win-end', there >>> is >>> a call to `(window-end win t)'. The `t' means "compute the up-to-date >>> position >>> if it isn't already recorded." The return value from this function is >>> clearly incorrect. The fact that the wrong window is selected is simply a >>> consequence of this. >>> >>> In the older Emacs (up to bzr revision 113752), this seems to work >>> correctly. However, in the newer (starting from bzt revision 113753) this >>> is broken. >>> >> > Hm...I just add debug printf() at the end of Fwindow_end, and see an > identical output for 24.3 and r115239 for this simple example: > > ./src/emacs -Q -font 6x10 -geometry 200x65 > C-h t > M-x follow-delete-other-windows-and-split > C-c . C-v > > So if someone has a elisp code that clearly shows that window-end is > broken, > please attach it to this bug at least. > > Dmitry > > > [-- Attachment #1.2: Type: text/html, Size: 3922 bytes --] [-- Attachment #2: check-follow-scroll-bug.el --] [-- Type: application/octet-stream, Size: 9076 bytes --] ;; Quickn'dirty follow-mode debug log package. (require 'follow) (defun my-wrap-follow-scroll-up (&optional arg) (interactive "P") (setq my-f1 (selected-window)) (follow-scroll-up arg) (setq my-f2 (selected-window))) ;; The problem obly manifests itself when bound to a key. (global-set-key (kbd "C-z") 'my-wrap-follow-scroll-up) (defvar my-post-log nil) (defvar my-post-do-log nil) (defun check-follow-log (what &rest extra) (if my-post-do-log (setq my-post-log (cons (cons what (cons (selected-window) extra)) my-post-log)))) (defun check-follow-report-log () (interactive) (with-output-to-temp-buffer "*Follow log*" (dolist (x (reverse my-post-log)) (princ x) (terpri)))) ;; Modified to support logging. (defun follow-calc-win-end (&optional win) "Calculate the end position for window WIN. Return (END-POS END-OF-BUFFER). Actually, the position returned is the start of the line after the last fully-visible line in WIN. If WIN is nil, the selected window is used." (check-follow-log "follow-calc-win-end") (let ((win (or win (selected-window)))) (let ((edges (window-inside-pixel-edges win))) (check-follow-log " edges" edges) (let ((ht (- (nth 3 edges) (nth 1 edges)))) (check-follow-log " ht" ht) (let ((last-line-pos (posn-point (posn-at-x-y 0 (1- ht) win)))) (check-follow-log " last-line-pos" last-line-pos) (if (pos-visible-in-window-p last-line-pos win) (progn (check-follow-log " Pos visible") (let ((end (window-end win t))) (check-follow-log " end" end) (list end (= end (point-max))))) (check-follow-log " Pos not visible") (list last-line-pos nil))))))) ;; Modified to support logging. (defun follow-post-command-hook () "Ensure that the windows in Follow mode are adjacent after each command." (unless (input-pending-p) (let ((follow-inside-post-command-hook t) (win (selected-window))) ;; Work in the selected window, not in the current buffer. (with-current-buffer (window-buffer win) (unless (and (symbolp this-command) (get this-command 'follow-mode-use-cache)) (setq follow-windows-start-end-cache nil))) (setq my-post-do-log (eq this-command 'my-wrap-follow-scroll-up)) (if my-post-do-log (setq my-post-log '())) (check-follow-adjust-window win (point))))) ;; Special version of `follow-adjust-window'. (defun check-follow-adjust-window (win dest) ;; Adjust the window WIN and its followers. (check-follow-log "Start") (with-current-buffer (window-buffer win) (check-follow-log "Start (inside w-c-b)") (when (and follow-mode (not (window-minibuffer-p win))) ; (check-follow-log "window-start" (window-start (car (follow-all-followers)))) ; (check-follow-log "window-end" (window-end (car (follow-all-followers)))) ; (check-follow-log "follow-calc-win-end" (follow-calc-win-end (car (follow-all-followers)))) ; (check-follow-log "follow-windows-start-end" (follow-windows-start-end (follow-all-followers))) (let* ((windows (follow-all-followers win)) (win-start-end (progn (follow-update-window-start (car windows)) (follow-windows-start-end windows))) (aligned (follow-windows-aligned-p win-start-end)) (visible (follow-pos-visible dest win win-start-end)) selected-window-up-to-date) (check-follow-log "Visible" visible) (check-follow-log "win-start-end" win-start-end) (unless (and aligned visible) (setq follow-windows-start-end-cache nil)) (check-follow-log "Before internal-forece-redisplay check") ;; Select a window to display point. (unless follow-internal-force-redisplay (if (eq dest (point-max)) ;; Be careful at point-max: the display can be aligned ;; while DEST can be visible in several windows. (cond ;; Select the current window, but only when the display ;; is correct. (When inserting characters in a tail ;; window, the display is not correct, as they are ;; shown twice.) ;; ;; Never stick to the current window after a deletion. ;; Otherwise, when typing `DEL' in a window showing ;; only the end of the file, a character would be ;; removed from the window above, which is very ;; unintuitive. ((and visible aligned (not (memq this-command '(backward-delete-char delete-backward-char backward-delete-char-untabify kill-region)))) (check-follow-log "Case 1") (follow-debug-message "Max: same")) ;; If the end is visible, and the window doesn't ;; seems like it just has been moved, select it. ((follow-select-if-end-visible win-start-end) (check-follow-log "Case 2") (follow-debug-message "Max: end visible") (setq visible t aligned nil) (goto-char dest)) ;; Just show the end... (t (check-follow-log "Case 3") (follow-debug-message "Max: default") (select-window (car (last windows))) (goto-char dest) (setq visible nil aligned nil))) ;; We're not at the end, here life is much simpler. (cond ;; This is the normal case! ;; It should be optimized for speed. ((and visible aligned) (check-follow-log "Case 4") (follow-debug-message "same")) ;; Pick a position in any window. If the display is ok, ;; this picks the `correct' window. ((follow-select-if-visible dest win-start-end) (check-follow-log "Case 5") (follow-debug-message "visible") (goto-char dest) ;; Perform redisplay, in case line is partially visible. (setq visible nil)) ;; Not visible anywhere else, lets pick this one. (visible (check-follow-log "Case 6") (follow-debug-message "visible in selected.")) ;; If DEST is before the first window start, select the ;; first window. ((< dest (nth 1 (car win-start-end))) (check-follow-log "Case 7") (follow-debug-message "before first") (select-window (car windows)) (goto-char dest) (setq visible nil aligned nil)) ;; If we can position the cursor without moving the first ;; window, do it. This is the case that catches `RET' at ;; the bottom of a window. ((follow-select-if-visible-from-first dest windows) (check-follow-log "Case 7") (follow-debug-message "Below first") (setq visible t aligned t)) ;; None of the above. Stick to the selected window. (t (check-follow-log "Case 8") (follow-debug-message "None") (setq visible nil aligned nil)))) (check-follow-log "Before selected window check") ;; If a new window was selected, make sure that the old is ;; not scrolled when the point is outside the window. (unless (eq win (selected-window)) (let ((p (window-point win))) (set-window-start win (window-start win) nil) (set-window-point win p)))) (unless visible ;; If point may not be visible in the selected window, ;; perform a redisplay; this ensures scrolling. (let ((opoint (point))) (redisplay) ;; If this `redisplay' moved point, we got clobbered by a ;; previous call to `set-window-start'. Try again. (when (/= (point) opoint) (goto-char opoint) (redisplay))) (setq selected-window-up-to-date t) (check-follow-log "AAA") (follow-avoid-tail-recenter) (setq win-start-end (follow-windows-start-end windows) follow-windows-start-end-cache nil aligned nil)) ;; Now redraw the windows around the selected window. (check-follow-log "BBB") (unless (and (not follow-internal-force-redisplay) (or aligned (follow-windows-aligned-p win-start-end)) (follow-point-visible-all-windows-p win-start-end)) (setq follow-internal-force-redisplay nil) (follow-redisplay windows (selected-window) selected-window-up-to-date) (setq win-start-end (follow-windows-start-end windows) follow-windows-start-end-cache nil) ;; The point can ends up in another window when DEST is at ;; the beginning of the buffer and the selected window is ;; not the first. It can also happen when long lines are ;; used and there is a big difference between the width of ;; the windows. (When scrolling one line in a wide window ;; which will cause a move larger that an entire small ;; window.) (unless (follow-pos-visible dest win win-start-end) (follow-select-if-visible dest win-start-end) (goto-char dest))) (check-follow-log "CCC") ;; If the region is visible, make it look good when spanning ;; multiple windows. ;; FIXME: Why not use `use-region-p' here? (when (region-active-p) (follow-maximize-region (selected-window) windows win-start-end))) (check-follow-log "DDD") ;; Whether or not the buffer was in follow mode, update windows ;; displaying the tail so that Emacs won't recenter them. (follow-avoid-tail-recenter)) (check-follow-log "End (inside w-c-b)")) (check-follow-log "End")) ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 11:01 ` Anders Lindgren @ 2013-11-26 14:12 ` martin rudalics 2013-11-26 14:25 ` Anders Lindgren 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-26 14:12 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957 > The problem only occurs under certain circumstances. `window-end' must > called from a post-command hook and the command that started it must be > bound to a key (not using M-x). Also, sometimes it seems to work correctly, > sometimes not, like every second time. (Take "must" with a grain of salt, > it might be possible to trigger the bug under other circumstances as well.) From what you found out so far I suppose that these changes * window.c (window_scroll_pixel_based) (window_scroll_line_based): Do not reset last_modified and last_overlay_modified counters. are responsible. Could you try to resetting window_end_valid in window_scroll like === modified file 'src/window.c' --- src/window.c 2013-11-06 18:41:31 +0000 +++ src/window.c 2013-11-26 14:07:05 +0000 @@ -4286,6 +4286,7 @@ else window_scroll_line_based (window, n, whole, noerror); + XWINDOW (window)->window_end_valid = 0; immediate_quit = 0; } and see what happens? martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 14:12 ` martin rudalics @ 2013-11-26 14:25 ` Anders Lindgren 2013-11-26 16:19 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Anders Lindgren @ 2013-11-26 14:25 UTC (permalink / raw To: martin rudalics; +Cc: Dmitry Antipov, 15957 [-- Attachment #1: Type: text/plain, Size: 1209 bytes --] Hi! Unfortunately, the problem is still there, as far as I can see. -- Anders On Tue, Nov 26, 2013 at 3:12 PM, martin rudalics <rudalics@gmx.at> wrote: > > The problem only occurs under certain circumstances. `window-end' must > > called from a post-command hook and the command that started it must be > > bound to a key (not using M-x). Also, sometimes it seems to work > correctly, > > sometimes not, like every second time. (Take "must" with a grain of salt, > > it might be possible to trigger the bug under other circumstances as > well.) > > From what you found out so far I suppose that these changes > > * window.c (window_scroll_pixel_based) > > (window_scroll_line_based): Do not reset last_modified and > > last_overlay_modified counters. > > are responsible. Could you try to resetting window_end_valid in > window_scroll like > > === modified file 'src/window.c' > --- src/window.c 2013-11-06 18:41:31 +0000 > +++ src/window.c 2013-11-26 14:07:05 +0000 > @@ -4286,6 +4286,7 @@ > else > window_scroll_line_based (window, n, whole, noerror); > > + XWINDOW (window)->window_end_valid = 0; > immediate_quit = 0; > } > > and see what happens? > > martin > [-- Attachment #2: Type: text/html, Size: 1767 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 14:25 ` Anders Lindgren @ 2013-11-26 16:19 ` martin rudalics 2013-11-26 17:03 ` Anders Lindgren 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-26 16:19 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957 > Unfortunately, the problem is still there, as far as I can see. Too bad. And if you applied the below? martin === modified file 'src/window.c' --- src/window.c 2013-11-06 18:41:31 +0000 +++ src/window.c 2013-11-26 16:14:03 +0000 @@ -1574,6 +1574,7 @@ if (NILP (noforce)) w->force_start = 1; w->update_mode_line = 1; + w->window_end_valid = 0; if (w != XWINDOW (selected_window)) /* Enforce full redisplay. FIXME: make it more selective. */ windows_or_buffers_changed = 26; @@ -4286,6 +4287,7 @@ else window_scroll_line_based (window, n, whole, noerror); + XWINDOW (window)->window_end_valid = 0; immediate_quit = 0; } ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 16:19 ` martin rudalics @ 2013-11-26 17:03 ` Anders Lindgren 2013-11-26 17:21 ` martin rudalics 2013-11-27 7:48 ` martin rudalics 0 siblings, 2 replies; 15+ messages in thread From: Anders Lindgren @ 2013-11-26 17:03 UTC (permalink / raw To: martin rudalics; +Cc: Dmitry Antipov, 15957 [-- Attachment #1: Type: text/plain, Size: 1229 bytes --] YES!!! That did the trick! When it comes to the first patch you sent, I just realized that it do fix another problem I've experienced (but not yet reported). When scrolling with a simple C-v and follow-mode is enabled, the other window only followed every second time the command was issued. In other words, I think that both patches should be applied. Thanks a bunch, I really appreciate it! -- Anders On Tue, Nov 26, 2013 at 5:19 PM, martin rudalics <rudalics@gmx.at> wrote: > Unfortunately, the problem is still there, as far as I can see. >> > > Too bad. And if you applied the below? > > martin > > > > === modified file 'src/window.c' > --- src/window.c 2013-11-06 18:41:31 +0000 > +++ src/window.c 2013-11-26 16:14:03 +0000 > @@ -1574,6 +1574,7 @@ > if (NILP (noforce)) > w->force_start = 1; > w->update_mode_line = 1; > + w->window_end_valid = 0; > if (w != XWINDOW (selected_window)) > /* Enforce full redisplay. FIXME: make it more selective. */ > windows_or_buffers_changed = 26; > @@ -4286,6 +4287,7 @@ > > else > window_scroll_line_based (window, n, whole, noerror); > > + XWINDOW (window)->window_end_valid = 0; > immediate_quit = 0; > } > > > > > [-- Attachment #2: Type: text/html, Size: 1970 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 17:03 ` Anders Lindgren @ 2013-11-26 17:21 ` martin rudalics 2013-11-27 7:48 ` martin rudalics 1 sibling, 0 replies; 15+ messages in thread From: martin rudalics @ 2013-11-26 17:21 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957 > When it comes to the first patch you sent, I just realized that it do fix > another problem I've experienced (but not yet reported). When scrolling > with a simple C-v and follow-mode is enabled, the other window only > followed every second time the command was issued. > > In other words, I think that both patches should be applied. The second one includes the first one ;-) Anyway, I'm afraid that this is not yet the whole story. Dmitry, please look again at your changes - maybe you can spot additional locations where some weaker resets (weaker in a sense like "the buffer might not have changed but the window end position did") are needed. Thanks, martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-26 17:03 ` Anders Lindgren 2013-11-26 17:21 ` martin rudalics @ 2013-11-27 7:48 ` martin rudalics 2014-01-04 14:12 ` martin rudalics 1 sibling, 1 reply; 15+ messages in thread From: martin rudalics @ 2013-11-27 7:48 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957 > In other words, I think that both patches should be applied. Done in revision#115255 on trunk. Thanks for the invaluable recipe, martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk 2013-11-27 7:48 ` martin rudalics @ 2014-01-04 14:12 ` martin rudalics 0 siblings, 0 replies; 15+ messages in thread From: martin rudalics @ 2014-01-04 14:12 UTC (permalink / raw To: Anders Lindgren; +Cc: Dmitry Antipov, 15957-done >> In other words, I think that both patches should be applied. > > Done in revision#115255 on trunk. Bug closed. Thanks, martin ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-01-04 14:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-22 22:23 bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk Anders Lindgren 2013-11-23 11:58 ` martin rudalics 2013-11-23 22:01 ` Anders Lindgren 2013-11-24 10:10 ` martin rudalics 2013-11-25 9:19 ` Anders Lindgren [not found] ` <CABr8ebbnxDgVF-+pdk955Ux-SQuZDONw=OhHOVUdO9d=xsTcZg@mail.gmail.com> 2013-11-25 16:42 ` martin rudalics 2013-11-26 6:33 ` Dmitry Antipov 2013-11-26 11:01 ` Anders Lindgren 2013-11-26 14:12 ` martin rudalics 2013-11-26 14:25 ` Anders Lindgren 2013-11-26 16:19 ` martin rudalics 2013-11-26 17:03 ` Anders Lindgren 2013-11-26 17:21 ` martin rudalics 2013-11-27 7:48 ` martin rudalics 2014-01-04 14:12 ` martin rudalics
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.