GNU bug report logs - #7910
23.2; inconsistent scrolling

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7910 in the body.
You can then email your comments to 7910 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Oleksandr Manzyuk <manzyuk <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; inconsistent scrolling
Date: Mon, 24 Jan 2011 20:49:33 +0000

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

1. M-x eval-expression RET (setq scroll-preserve-screen-position t) RET

2. Open a long file that takes up more than one screen.

3. Make sure that the beginning of the file is at the top of the screen
and go to a line near the bottom of the screen.

4. Press C-l to bring that line to the center of the screen.

5. Press M-v and then C-v.

The expected behavior is that point goes back to the line where it
started.  It is not so, however.  When M-v is pressed, the window is
scrolled so that the beginning of the file is at the top of the screen
and point is placed in the center-most line.  When C-v is subsequently
pressed, the window is scrolled up one screenful, and the position of
point relative to the screen is preserved, so point ends up in the
center-most line.

I would like to remark that if I perform dual actions near the end of
the file, then scrolling is consistent: if the end of the file is not
visible and scrolling the window one screenful up would bring the point
past the end of the file, the window is scrolled so that the point ends
up at the last line of the file (which is put in the center of the
window), and subsequently pressing M-v brings point back to the line
where it started.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/23.2/etc/DEBUG.


In GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2010-09-02 on pluot, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  '--build=x86_64-linux-gnu'
'--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var/lib'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim'
'--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu'
'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x b s c r C-g ( s e t q SPC s c r o l l - p r e s
<M-tab> SPC t ) C-x C-e C-x C-f . e m a <tab> <return>
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-l <prior> M-x r e p o r t SPC e m
a c s SPC b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
t
Loading vc-git...done

Load-path shadows:
/usr/share/emacs/23.2/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.2/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/23.2/lisp/textmodes/ispell
/usr/share/emacs/23.2/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/23.2/lisp/textmodes/flyspell
/usr/share/emacs/23.2/site-lisp/ruby1.9.1-elisp/ruby-mode hides
/usr/share/emacs/23.2/lisp/progmodes/ruby-mode

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
easymenu mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug vc-git
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
font-setting tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind system-font-setting
font-render-setting gtk x-toolkit x multi-tty emacs)

Message #8 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Oleksandr Manzyuk <manzyuk <at> gmail.com>
Cc: 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Tue, 08 Dec 2020 16:46:20 +0100

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

Oleksandr Manzyuk <manzyuk <at> gmail.com> writes:

> 1. M-x eval-expression RET (setq scroll-preserve-screen-position t) RET
>
> 2. Open a long file that takes up more than one screen.
>
> 3. Make sure that the beginning of the file is at the top of the screen
> and go to a line near the bottom of the screen.
>
> 4. Press C-l to bring that line to the center of the screen.
>
> 5. Press M-v and then C-v.
>
> The expected behavior is that point goes back to the line where it
> started.  It is not so, however.  When M-v is pressed, the window is
> scrolled so that the beginning of the file is at the top of the screen
> and point is placed in the center-most line.

(This bug report unfortunately got no response at the time.)

I'm not quite sure I follow the recipe here, but if I understand you
correctly, then a simpler recipe is simply:


emacs -Q src/alloc.c
M-: (setq scroll-preserve-screen-position t) RET

Then move point down to the next-to-last line

[Message part 2 (image/png, inline)]

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

Then hit `C-v':

[Message part 4 (image/png, inline)]

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

Point is moved to the first visible line in the window instead of
remaining at the next-to-last line.

If you do this anywhere else in the buffer (except the last two lines
(and the first two lines)), the visual point is kept the same place.

I don't use this setting myself, so I'm wondering -- is this intended
behaviour (i.e., sorta not using the setting on the two first/last
lines), or is this a bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Tue, 08 Dec 2020 20:31:35 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 08 Dec 2020 16:46:20 +0100
> Cc: 7910 <at> debbugs.gnu.org
> 
> emacs -Q src/alloc.c
> M-: (setq scroll-preserve-screen-position t) RET
> 
> Then move point down to the next-to-last line
> 
> Then hit `C-v':
> 
> Point is moved to the first visible line in the window instead of
> remaining at the next-to-last line.
> 
> If you do this anywhere else in the buffer (except the last two lines
> (and the first two lines)), the visual point is kept the same place.
> 
> I don't use this setting myself, so I'm wondering -- is this intended
> behaviour (i.e., sorta not using the setting on the two first/last
> lines), or is this a bug?

It's according to the doc string, AFAICT.  If the OP wants the cursor
to _always_ retain its screen position, he should set
scroll-preserve-screen-position to a non-nil. non-t value.

Message #16 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Wed, 09 Dec 2020 13:38:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> It's according to the doc string, AFAICT.  If the OP wants the cursor
> to _always_ retain its screen position, he should set
> scroll-preserve-screen-position to a non-nil. non-t value.

Setting the variable to `always' works for me, but the doc string is
misleading here.

---
A value of t means point keeps its screen position if the scroll
command moved it vertically out of the window, e.g. when scrolling
by full screens.
---

If you're on the next-to-last line, `C-v' will not move point out of the
window -- the next-to-last line will end up as the first line.

And there's further peculiarities with the t setting -- if you're at the
next-to-last visual line, `C-v' will put point on the first visual
line.  `C-v' again, and it's on the next-to-last line again.  So it'll
alternate first/next-to-last after every `C-v'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Wed, 09 Dec 2020 17:38:56 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: manzyuk <at> gmail.com,  7910 <at> debbugs.gnu.org
> Date: Wed, 09 Dec 2020 13:38:05 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > It's according to the doc string, AFAICT.  If the OP wants the cursor
> > to _always_ retain its screen position, he should set
> > scroll-preserve-screen-position to a non-nil. non-t value.
> 
> Setting the variable to `always' works for me, but the doc string is
> misleading here.
> 
> ---
> A value of t means point keeps its screen position if the scroll
> command moved it vertically out of the window, e.g. when scrolling
> by full screens.
> ---
> 
> If you're on the next-to-last line, `C-v' will not move point out of the
> window -- the next-to-last line will end up as the first line.
> 
> And there's further peculiarities with the t setting -- if you're at the
> next-to-last visual line, `C-v' will put point on the first visual
> line.  `C-v' again, and it's on the next-to-last line again.  So it'll
> alternate first/next-to-last after every `C-v'.

The special "status" of the two lines at bottom is because the default
value of next-screen-context-lines is 2.

It sounds like you did understand the doc string, given your
description.  I wouldn't say it's misleading, just that it only hints
on when screen position will not be kept, instead of describing that
in detail, and in particular doesn't mention
next-screen-context-lines.  Would you like to suggest an amendment to
the doc string that would clarify that?

Message #22 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Wed, 09 Dec 2020 16:41:47 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> It sounds like you did understand the doc string, given your
> description.

No, I didn't.  :-)

> I wouldn't say it's misleading, just that it only hints
> on when screen position will not be kept, instead of describing that
> in detail, and in particular doesn't mention
> next-screen-context-lines.  Would you like to suggest an amendment to
> the doc string that would clarify that?

Sure, if you confirm that the
alternating-between-point-on-top-and-bottom-of-the-screen is intended
behaviour, and not a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #25 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Wed, 09 Dec 2020 17:54:48 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: manzyuk <at> gmail.com,  7910 <at> debbugs.gnu.org
> Date: Wed, 09 Dec 2020 16:41:47 +0100
> 
> > I wouldn't say it's misleading, just that it only hints
> > on when screen position will not be kept, instead of describing that
> > in detail, and in particular doesn't mention
> > next-screen-context-lines.  Would you like to suggest an amendment to
> > the doc string that would clarify that?
> 
> Sure, if you confirm that the
> alternating-between-point-on-top-and-bottom-of-the-screen is intended
> behaviour, and not a bug.

I don't think it's a bug.

(Disclosure: I understand how this feature works, but I don't
understand the rationale for it, or why it is useful.  So my opinion
that this is not a bug should be taken with a grain of salt.)

Message #28 received at 7910 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: manzyuk <at> gmail.com, 7910 <at> debbugs.gnu.org
Subject: Re: bug#7910: 23.2; inconsistent scrolling
Date: Wed, 09 Dec 2020 20:41:45 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Sure, if you confirm that the
>> alternating-between-point-on-top-and-bottom-of-the-screen is intended
>> behaviour, and not a bug.
>
> I don't think it's a bug.

After looking at it a bit more, I agree with you that this is probably
working as intended...

> (Disclosure: I understand how this feature works, but I don't
> understand the rationale for it, or why it is useful.  So my opinion
> that this is not a bug should be taken with a grain of salt.)

... even if it's a bit difficult to understand the reasoning for the
feature at all.  So I've just clarified the doc string that the t
setting is rather odd, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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