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

Previous Next

Full log

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

Previous Next

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