GNU bug report logs - #15957
24.3.50; Follow mode scrolling broken on Emacs trunk

Previous Next

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

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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Fri, 22 Nov 2013 23:23:37 +0100

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

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

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Sat, 23 Nov 2013 12:58:47 +0100

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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Sat, 23 Nov 2013 23:01:24 +0100

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

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

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Sun, 24 Nov 2013 11:10:32 +0100

> 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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Mon, 25 Nov 2013 10:19:38 +0100

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

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

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Mon, 25 Nov 2013 17:42:21 +0100

Forwarding Anders Lindgren's mail to 15957 <at> 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 <at> 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 <at> 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 <at> 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
>>>
>>
> 

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

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: martin rudalics <rudalics <at> gmx.at>, 
 Anders Lindgren <andlind <at> gmail.com>
Cc: 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 10:33:17 +0400

On 11/25/2013 08:42 PM, martin rudalics wrote:
> Forwarding Anders Lindgren's mail to 15957 <at> 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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: martin rudalics <rudalics <at> gmx.at>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 12:01:13 +0100

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

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 <at> yandex.ru> wrote:

> On 11/25/2013 08:42 PM, martin rudalics wrote:
>
>> Forwarding Anders Lindgren's mail to 15957 <at> 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
>
>
>

[Message part 2 (text/html, inline)]

[check-follow-scroll-bug.el (application/octet-stream, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 15:12:45 +0100

> 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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 15:25:48 +0100

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

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

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 17:19:37 +0100

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

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 18:03:38 +0100

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

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

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Tue, 26 Nov 2013 18:21:48 +0100

> 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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957 <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Wed, 27 Nov 2013 08:48:50 +0100

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

Done in revision#115255 on trunk.

Thanks for the invaluable recipe, martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 15957-done <at> debbugs.gnu.org
Subject: Re: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Sat, 04 Jan 2014 15:12:29 +0100

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

Bug closed.

Thanks, martin

Previous Next

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