bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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 --]

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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 --]

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

 > 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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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 --]

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Dmitry Antipov]

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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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"))

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

 > 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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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 --]

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

> 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;
  }

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[Anders Lindgren]

[-- 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 --]

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

 > 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

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

> In other words, I think that both patches should be applied.

Done in revision#115255 on trunk.

Thanks for the invaluable recipe, martin

bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk

[martin rudalics]

>> In other words, I think that both patches should be applied.
> 
> Done in revision#115255 on trunk.

Bug closed.

Thanks, martin