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

Previous Next

Full log

View this message in rfc822 format

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 15957 <at> debbugs.gnu.org
Subject: bug#15957: 24.3.50; Follow mode scrolling broken on Emacs trunk
Date: Sat, 23 Nov 2013 23:01:24 +0100

[Message part 1 (text/plain, inline)]

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 <rudalics <at> gmx.at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

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