From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk Date: Mon, 25 Nov 2013 10:19:38 +0100 Message-ID: References: <52909877.1070203@gmx.at> <5291D098.10507@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c37e30f7a56304ebfcdcd4 X-Trace: ger.gmane.org 1385371213 28068 80.91.229.3 (25 Nov 2013 09:20:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Nov 2013 09:20:13 +0000 (UTC) Cc: 15957@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 25 10:20:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VksL3-0006Ea-Fw for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Nov 2013 10:20:17 +0100 Original-Received: from localhost ([::1]:50445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VksL2-0002JF-Vp for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Nov 2013 04:20:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VksKu-0002Ht-CU for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 04:20:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VksKp-0002wT-GQ for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 04:20:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VksKp-0002wD-Bl for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 04:20:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VksKo-0005vf-Ji for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2013 04:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Nov 2013 09:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15957 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15957-submit@debbugs.gnu.org id=B15957.138537118722765 (code B ref 15957); Mon, 25 Nov 2013 09:20:02 +0000 Original-Received: (at 15957) by debbugs.gnu.org; 25 Nov 2013 09:19:47 +0000 Original-Received: from localhost ([127.0.0.1]:43480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VksKY-0005v6-OK for submit@debbugs.gnu.org; Mon, 25 Nov 2013 04:19:47 -0500 Original-Received: from mail-we0-f173.google.com ([74.125.82.173]:42044) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VksKW-0005um-6b for 15957@debbugs.gnu.org; Mon, 25 Nov 2013 04:19:45 -0500 Original-Received: by mail-we0-f173.google.com with SMTP id t61so3510893wes.18 for <15957@debbugs.gnu.org>; Mon, 25 Nov 2013 01:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+SVnFXHaMAH71HH2FHGmMJuM942nMKkTl56Cn0QaZ3o=; b=bRVB3kxiJ1qxxCi+cpXPg2abe+Rh/J2ahxOOGxn56PAiB4kuw9AnwGW5fnar0PvvOt Ib5bLMrGsPK+8D1AsdPmkomCMP+YJCKIEOgM+Bh/Xu2E1xRxU90WvxppWNWLyfczYzRi ktc39I/i9MNy26UaecDdoVY6uuOj5DoYhShA+dIQSJVxX+Hc9cWUgeKf7it7fg88Tora SWn6XhX9vqSMDK8/AXCpDEWdyK8ndRDRy1u8t8UsG9yRxbHqfvtIdXi8fixRXfym2WQz vvTfS8XW95gjwUtw8h0OHz3elQN81TIM/22yrfDVa3/IkxwYHt/fJybNC7NlOY+fvBlr Re9g== X-Received: by 10.180.208.49 with SMTP id mb17mr12787765wic.64.1385371178344; Mon, 25 Nov 2013 01:19:38 -0800 (PST) Original-Received: by 10.216.124.76 with HTTP; Mon, 25 Nov 2013 01:19:38 -0800 (PST) In-Reply-To: <5291D098.10507@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80940 Archived-At: --001a11c37e30f7a56304ebfcdcd4 Content-Type: text/plain; charset=ISO-8859-1 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 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 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 > --001a11c37e30f7a56304ebfcdcd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

I tried something similar to the co= de 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 ar= ound worked correctly, so I have spent some time to do a binary search of t= he bzr archive and found out that this broke in revision=A0113753, 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:

=A0 Do not reset window modification event counters excessive= ly.

=A0 These leftovers and poor man's tricky methods to catc= h extra

=A0 redisplay's attention are no longer needed.

=A0 * frame.c (set_menu_bar_lines_1):

=A0 * minibuf.c (read_minibuf_unwind):

=A0 * window.c (Fset_window_start, set_window_buffer, window_= resize_apply)

=A0 (grow_mini_window, shrink_mini_window, window_scroll_pixe= l_based)

=A0 (window_scroll_line_based, Fset_window_configuration):

=A0 * xdisp.c (redisplay_window): Do not reset last_modified = and

=A0 last_overlay_modified counters.


=

I will continue to narrow down the problem in the post-comman= d hook, I'll let you know when I'm done.


<= p class=3D""> Sincerely,

=A0 =A0 Anders Lindgren




On Sun, Nov 24, 2013 at 11:10 AM, martin rudalics <rudalics@gmx.at><= /span> wrote:
> I really doubt that t= he 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 t= hat
> 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<= br> > 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 funct= ion
> 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. =A0So<= br> maybe you should try the change I suggested.


> This is also the reason why reported this as a bug, rather than diggin= g
> into the code myself. However, I could try to add log code to Follow m= ode,
> to check if I could try to figure out what is going on.

Please do that.

Thanks, martin

--001a11c37e30f7a56304ebfcdcd4--