GNU bug report logs -
#925
23.0.60; follow-mode doesn't work in buffers with a header line
Previous Next
Reported by: Phil Sung <psung <at> mit.edu>
Date: Sun, 7 Sep 2008 22:35:04 UTC
Severity: normal
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 925 in the body.
You can then email your comments to 925 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#925
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Phil Sung <psung <at> mit.edu>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Steps to reproduce:
0. emacs -Q
1. C-h r [info-emacs-manual]
2. C-x 3 [split-window-horizontally]
3. M-x follow-mode
4. C-n until point moves past bottom of window
Expected results:
Point moves to top of next window.
Actual results:
First window scrolls down and then recenters around point.
In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.13.7)
of 2008-08-31 on iridium, modified by Debian
(emacs-snapshot package, version 1:20080831-1)
configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#925
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #10 received at 925 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Steps to reproduce:
>
> 0. emacs -Q
> 1. C-h r [info-emacs-manual]
> 2. C-x 3 [split-window-horizontally]
> 3. M-x follow-mode
> 4. C-n until point moves past bottom of window
>
> Expected results:
>
> Point moves to top of next window.
>
> Actual results:
>
> First window scrolls down and then recenters around point.
Does it help when you set `scroll-conservatively' to 100?
martin
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#925
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Phil Sung <psung <at> mit.edu>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #15 received at 925 <at> emacsbugs.donarmstrong.com (full text, mbox):
martin rudalics writes:
> Does it help when you set `scroll-conservatively' to 100?
No, it doesn't. When I do that, not only does the expected behavior
not happen, point moves back to the center of the first screen. This
didn't happen with the default value of scroll-conservatively.
Here's what I now think is going on:
When there's a header line, follow-mode miscomputes the beginning of
the second window-- if you try out the "steps to reproduce", you can
see that there's one line after the end of the first window which is
not visible in the second window. When you try to C-n to that line,
follow-mode can't display that line in either window, so something
weird happens.
I tried the (flawed) patch below, which decreases the effective
window-height when there's a header line. I'm not sure if this is the
right approach.
With this patch, point correctly moves from one window to the other,
and the two windows display consecutive lines, as expected. However,
sometimes when moving point between windows, the text will shift up or
down by a line. I don't know why that happens.
Thanks,
Phil
follow.el (follow-scroll-down, follow-calc-win-end,
follow-estimate-first-window-start): reduce effective window
height when header line is present.
diff --git a/lisp/follow.el b/lisp/follow.el
index 508d0f5..766dfce 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -624,7 +624,7 @@ Works like `scroll-up' when not in Follow mode."
(select-window win)
(goto-char start)
(vertical-motion (- (- (window-height win)
- 1
+ (if header-line-format 2 1)
next-screen-context-lines)))
(set-window-start win (point))
(goto-char start)
@@ -887,7 +887,8 @@ Returns (end-pos end-of-buffer-p)"
(prog1
(save-excursion
(goto-char (window-start))
- (setq height (- (window-height) 1))
+ (setq height (- (window-height)
+ (if header-line-format 2 1)))
(setq buffer-end-p
(if (bolp)
(not (= height (vertical-motion height)))
@@ -1219,7 +1220,9 @@ position of the first window. Otherwise it is a good guess."
;(setq exact (bolp))
(vertical-motion 0 win)
(while pred
- (vertical-motion (- 1 (window-height (car pred))) (car pred))
+ (vertical-motion (- (if header-line-format 2 1)
+ (window-height (car pred)))
+ (car pred))
(if (not (bolp))
(setq exact nil))
(setq pred (cdr pred)))
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#925
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #20 received at 925 <at> emacsbugs.donarmstrong.com (full text, mbox):
> No, it doesn't. When I do that, not only does the expected behavior
> not happen, point moves back to the center of the first screen. This
> didn't happen with the default value of scroll-conservatively.
I don't understand well. When I set `scroll-conservatively' to 100
there's no recentering with emacs -Q and both windows scroll. There's,
however, at least one line missing as you remark below.
> Here's what I now think is going on:
>
> When there's a header line, follow-mode miscomputes the beginning of
> the second window-- if you try out the "steps to reproduce", you can
> see that there's one line after the end of the first window which is
> not visible in the second window. When you try to C-n to that line,
> follow-mode can't display that line in either window, so something
> weird happens.
>
> I tried the (flawed) patch below, which decreases the effective
> window-height when there's a header line. I'm not sure if this is the
> right approach.
Ideally, the second window wouldn't display the header line at all.
> With this patch, point correctly moves from one window to the other,
> and the two windows display consecutive lines, as expected. However,
> sometimes when moving point between windows, the text will shift up or
> down by a line. I don't know why that happens.
This seems to already happen without your patch.
martin
Reply sent to
martin rudalics <rudalics <at> gmx.at>
:
You have taken responsibility.
Full text and
rfc822 format available.
Notification sent to
Phil Sung <psung <at> mit.edu>
:
bug acknowledged by developer.
Full text and
rfc822 format available.
Message #25 received at 925-done <at> emacsbugs.donarmstrong.com (full text, mbox):
Fixed as
2008-10-28 Phil Sung <psung <at> mit.edu> (tiny change)
* follow.el (follow-scroll-down, follow-calc-win-end)
(follow-estimate-first-window-start): Reduce effective window
height when header line is present. (Bug#925)
Thanks, martin
bug archived.
Request was from
Debbugs Internal Request <don <at> donarmstrong.com>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Wed, 26 Nov 2008 15:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 208 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.