[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: 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 address@hidden and Dmitry Antipov.


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

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.

    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 <address@hidden> wrote:


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 <address@hidden>

branch nick: trunk

timestamp: Thu 2013-08-08 08:42:40 +0400


  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.


    Anders Lindgren

On Sun, Nov 24, 2013 at 11:10 AM, martin rudalics <address@hidden> wrote:

I really doubt that the code in `follow-scroll-up' is broken.
I didn't say so.

is designed so that the rearrangement of the other windows (the ones
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,
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
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
to check if I could try to figure out what is going on.
Please do that.

Thanks, martin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]