From: martin rudalics <rudalics@gmx.at>
To: Anders Lindgren <andlind@gmail.com>
Cc: Dmitry Antipov <dmantipov@yandex.ru>, 15957@debbugs.gnu.org
Subject: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Mon, 25 Nov 2013 17:42:21 +0100 [thread overview]
Message-ID: <52937DED.9070304@gmx.at> (raw)
In-Reply-To: <CABr8ebbnxDgVF-+pdk955Ux-SQuZDONw=OhHOVUdO9d=xsTcZg@mail.gmail.com>
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
>>>
>>
>
next prev parent reply other threads:[~2013-11-25 16:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52937DED.9070304@gmx.at \
--to=rudalics@gmx.at \
--cc=15957@debbugs.gnu.org \
--cc=andlind@gmail.com \
--cc=dmantipov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.