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: Sat, 23 Nov 2013 23:01:24 +0100 Message-ID: References: <52909877.1070203@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec53f382f950bfb04ebdf4567 X-Trace: ger.gmane.org 1385244134 30996 80.91.229.3 (23 Nov 2013 22:02:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Nov 2013 22:02:14 +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 Sat Nov 23 23:02:19 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 1VkLHN-000292-NR for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Nov 2013 23:02:17 +0100 Original-Received: from localhost ([::1]:45198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkLHN-0002jx-Cd for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Nov 2013 17:02:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkLHF-0002jc-HA for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2013 17:02:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkLH9-0008RR-JF for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2013 17:02:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkLH9-0008RN-Do for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2013 17:02:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VkLH8-0000Gj-TP for bug-gnu-emacs@gnu.org; Sat, 23 Nov 2013 17:02:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Nov 2013 22:02: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.1385244094993 (code B ref 15957); Sat, 23 Nov 2013 22:02:02 +0000 Original-Received: (at 15957) by debbugs.gnu.org; 23 Nov 2013 22:01:34 +0000 Original-Received: from localhost ([127.0.0.1]:40611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VkLGf-0000Fv-P8 for submit@debbugs.gnu.org; Sat, 23 Nov 2013 17:01:34 -0500 Original-Received: from mail-we0-f172.google.com ([74.125.82.172]:39675) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VkLGc-0000Fg-QV for 15957@debbugs.gnu.org; Sat, 23 Nov 2013 17:01:31 -0500 Original-Received: by mail-we0-f172.google.com with SMTP id t60so2480446wes.31 for <15957@debbugs.gnu.org>; Sat, 23 Nov 2013 14:01:24 -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=WWjgGbYRmsJH4AgfyJSGQOJz7mUmWQRyPk6FAt3dLEg=; b=W4dhdMQ8PQ4w8zn9EkfucN+EpyF9g+ioExl2fLcvohJkkpJDB6cqr0vaTe/DFRVKug hVwfb+mO+jR54l5x3Mc7ilyMHeXIlCbd+EgJYWuhPeI16u3bXQIb15DPY5dYIDonMdAR iduKH6RHqgl/DPf/tM5n6HAxmOH5cwoBJJBJWYATslqmkcMg/BOuc7Eihsufpfdr5CTK /blxy5d7Sf5ZYetc3AnzTAg9JXe5DI4pYlOuw+KB6CfjiBDrXNr9ps/kAL7ljmyA/YMo CWGQag+ET22S6vstx4zLLvgOCKpazAo51TTkbAWx42ewJ6gO5OprpzUw40WmY6/00P9F NjdQ== X-Received: by 10.180.20.102 with SMTP id m6mr7933679wie.22.1385244084471; Sat, 23 Nov 2013 14:01:24 -0800 (PST) Original-Received: by 10.216.124.76 with HTTP; Sat, 23 Nov 2013 14:01:24 -0800 (PST) In-Reply-To: <52909877.1070203@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:80885 Archived-At: --bcaec53f382f950bfb04ebdf4567 Content-Type: text/plain; charset=ISO-8859-1 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 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 > --bcaec53f382f950bfb04ebdf4567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!

No, the actual numbers don't ap= pear to be important. I simply picked some numbers to make sure the frame w= as wide enough for two side-by-side windows. I tried 40 instead of 70 and y= ou 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 w= indows (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 mec= hanism fail. This could also account for the difference we see when the fun= ction is called via a key sequence as compared to via M-x.

This is also the reason why reported this as a bug, rat= her 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.

=A0 =A0 -- Anders





On Sat, Nov 23, 2013 at 12:58 PM, martin rudalics &= lt;rudalics@gmx.at= > wrote:
Hi Anders

> Scrolling multiple pages when Follow mode is enabled sometimes fails.<= br> >
> Steps to repeat:
>
> =A0 =A0 Emacs -Q
> =A0 =A0 C-h t
> =A0 =A0 ESC : (set-frame-size (selected-frame) 200 70) RET

Is this really necessary? =A070 lines means I can't see my echo area an= y
more.

> =A0 =A0 M-x follow-delete-other-windows-and-split RET
> =A0 =A0 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 th= e
> 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

=A0 =A0 =A0 =A0 =A0(let* ((windows (follow-all-followers))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (end (window-end (car (reverse windows)))))=
=A0 =A0 =A0 =A0 =A0 =A0(if (eq end (point-max))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(signal 'end-of-buffer nil)
=A0 =A0 =A0 =A0 =A0 =A0 =A0(select-window (car windows))

which seems to imply that `follow-all-followers' doesn't return wha= t it
is supposed to. =A0Am I correct that the first window returned by the
latter should be `frame-first-window'? =A0In that case try to replace t= he
last line of `follow-all-followers' by something like

=A0 =A0 (prog1
=A0 =A0 =A0 =A0 (setq windows (sort windows 'follow--window-sorter)) =A0 =A0 =A0 (unless (eq (car windows) (frame-first-window (window-frame win= )))
=A0 =A0 =A0 =A0 (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 w= orks,
> 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<= br> > 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 h= aven't
> touched it for many years.

I suppose you should touch it again ;-)

martin

--bcaec53f382f950bfb04ebdf4567--