bug#662: 23.0.60; Constant recentering with scroll-margin set

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Ralf Angeli]

Start Emacs with
emacs -Q -eval "(progn (setq scroll-margin 1) (dotimes (i 100) (newline)))"
and start typing in the scratch buffer.  With nearly every new line
which is inserted, the buffer is recentered.


In GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2008-08-06 on photon
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
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: Lisp Interaction

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

Recent input:
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Chong Yidong]

> Start Emacs with emacs -Q -eval "(progn (setq scroll-margin 1)
> (dotimes (i 100) (newline)))" and start typing in the scratch buffer.
> With nearly every new line which is inserted, the buffer is
> recentered.

Could you try to provide a more precise recipe?  I'm not sure what you
mean.

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Chong Yidong]

Actually, I see the bug now.  I've made some changes to CVS that ought
to fix it.  Does it work for you now?

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Ralf Angeli]

* Chong Yidong (2008-08-07) writes:

> Actually, I see the bug now.  I've made some changes to CVS that ought
> to fix it.  Does it work for you now?

It's better, but it doesn't seem to be totally fixed.  There is still
some recentering happening when scrolling a long article in Gnus.  If
you type <RET> to scroll, the bottom of the article will be reached
eventually and once this happens, the buffer will be recentered and the
last line jumps to the middle of the window.

-- 
Ralf

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Ralf Angeli]

* Ralf Angeli (2008-08-07) writes:

> * Chong Yidong (2008-08-07) writes:
>
>> Actually, I see the bug now.  I've made some changes to CVS that ought
>> to fix it.  Does it work for you now?
>
> It's better, but it doesn't seem to be totally fixed.  There is still
> some recentering happening when scrolling a long article in Gnus.  If
> you type <RET> to scroll, the bottom of the article will be reached
> eventually and once this happens, the buffer will be recentered and the
> last line jumps to the middle of the window.

It could also be that this has to be fixed in Gnus.  I'm not sure, but I
remember that there was a similar issue back in 2005 where some changes
hat to be made in `gnus-article-next-page' and related functions in
order to deal with some changes in the handling of `scroll-margin'.

-- 
Ralf

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Ralf Angeli]

* Ralf Angeli (2008-08-07) writes:

> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
> remember that there was a similar issue back in 2005 where some changes
> hat to be made in `gnus-article-next-page' and related functions in
> order to deal with some changes in the handling of `scroll-margin'.

Okay, the problem is the statement
(move-to-window-line -1)
in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
0 it will lead to a recentering.  This is usually countered by
`gnus-article-next-page-1', but not at the end of an article where
`gnus-article-next-page-1' will not be called.

The problem can be circumvented by changing the above statement to
(move-to-window-line (- -1 scroll-margin))

Let me know if the recentering behavior will stay like it is now, then I
can report this to the Gnus maintainers.

-- 
Ralf

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Stefan Monnier]

>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>> remember that there was a similar issue back in 2005 where some changes
>> hat to be made in `gnus-article-next-page' and related functions in
>> order to deal with some changes in the handling of `scroll-margin'.

> Okay, the problem is the statement
> (move-to-window-line -1)
> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
> 0 it will lead to a recentering.  This is usually countered by
> `gnus-article-next-page-1', but not at the end of an article where
> `gnus-article-next-page-1' will not be called.

> The problem can be circumvented by changing the above statement to
> (move-to-window-line (- -1 scroll-margin))

> Let me know if the recentering behavior will stay like it is now, then I
> can report this to the Gnus maintainers.

BTW, shouldn't Gnus "just" set scroll-margin (and such things)
buffer-locally in its article buffer, so as to isolate it from
such problems?
Or maybe not buffer-locally but let-bound around a call to redisplay?


        Stefan

bug#662: 23.0.60; Constant recentering with scroll-margin set

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Ralf Angeli" <angeli@caeruleus.net>
To: "Chong Yidong" <cyd@stupidchicken.com>
Cc: <662@emacsbugs.donarmstrong.com>
Sent: Saturday, August 09, 2008 3:32 AM
Subject: bug#662: 23.0.60; Constant recentering with scroll-margin set


>* Ralf Angeli (2008-08-07) writes:
>
>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>> remember that there was a similar issue back in 2005 where some changes
>> hat to be made in `gnus-article-next-page' and related functions in
>> order to deal with some changes in the handling of `scroll-margin'.
>
> Okay, the problem is the statement
> (move-to-window-line -1)
> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
> 0 it will lead to a recentering.  This is usually countered by
> `gnus-article-next-page-1', but not at the end of an article where
> `gnus-article-next-page-1' will not be called.
>
> The problem can be circumvented by changing the above statement to
> (move-to-window-line (- -1 scroll-margin))
>
> Let me know if the recentering behavior will stay like it is now, then I
> can report this to the Gnus maintainers.
>
> -- 
> Ralf
>
>
>
> 

bug#662: 23.0.60; Constant recentering with scroll-margin set

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Ralf Angeli" <angeli@caeruleus.net>
To: "Chong Yidong" <cyd@stupidchicken.com>
Cc: <662@emacsbugs.donarmstrong.com>
Sent: Saturday, August 09, 2008 3:32 AM
Subject: bug#662: 23.0.60; Constant recentering with scroll-margin set


>* Ralf Angeli (2008-08-07) writes:
>
>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>> remember that there was a similar issue back in 2005 where some changes
>> hat to be made in `gnus-article-next-page' and related functions in
>> order to deal with some changes in the handling of `scroll-margin'.
>
> Okay, the problem is the statement
> (move-to-window-line -1)
> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
> 0 it will lead to a recentering.  This is usually countered by
> `gnus-article-next-page-1', but not at the end of an article where
> `gnus-article-next-page-1' will not be called.
>
> The problem can be circumvented by changing the above statement to
> (move-to-window-line (- -1 scroll-margin))
>
> Let me know if the recentering behavior will stay like it is now, then I
> can report this to the Gnus maintainers.
>
> -- 
> Ralf
>
>
>
> 

Re: 23.0.60; Constant recentering with scroll-margin set

[Chong Yidong]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Ralf Angeli (2008-08-07) writes:
>
>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>> remember that there was a similar issue back in 2005 where some changes
>> hat to be made in `gnus-article-next-page' and related functions in
>> order to deal with some changes in the handling of `scroll-margin'.
>
> Okay, the problem is the statement
> (move-to-window-line -1)
> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
> 0 it will lead to a recentering.  This is usually countered by
> `gnus-article-next-page-1', but not at the end of an article where
> `gnus-article-next-page-1' will not be called.
>
> The problem can be circumvented by changing the above statement to
> (move-to-window-line (- -1 scroll-margin))
>
> Let me know if the recentering behavior will stay like it is now, then
> I can report this to the Gnus maintainers.

What do people think?  When there is a scroll-margin, should
move-to-window-line automagically move to the scroll-margin instead of
recentering?

Re: 23.0.60; Constant recentering with scroll-margin set

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> Ralf Angeli <angeli@caeruleus.net> writes:
> 
>> * Ralf Angeli (2008-08-07) writes:
>>
>>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>>> remember that there was a similar issue back in 2005 where some changes
>>> hat to be made in `gnus-article-next-page' and related functions in
>>> order to deal with some changes in the handling of `scroll-margin'.
>> Okay, the problem is the statement
>> (move-to-window-line -1)
>> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
>> 0 it will lead to a recentering.  This is usually countered by
>> `gnus-article-next-page-1', but not at the end of an article where
>> `gnus-article-next-page-1' will not be called.
>>
>> The problem can be circumvented by changing the above statement to
>> (move-to-window-line (- -1 scroll-margin))
>>
>> Let me know if the recentering behavior will stay like it is now, then
>> I can report this to the Gnus maintainers.
> 
> What do people think?  When there is a scroll-margin, should
> move-to-window-line automagically move to the scroll-margin instead of
> recentering?

Yes. Automatic recentering is very disturbing IMO.

bug#662: 23.0.60; Constant recentering with scroll-margin set

[ＯＦＦＩＣＥ ZERO]

Do'nt   send  me mail  !!!
no tkank you!!

----- Original Message ----- 
From: "Ralf Angeli" <angeli@caeruleus.net>
To: "Chong Yidong" <cyd@stupidchicken.com>
Cc: <662@emacsbugs.donarmstrong.com>
Sent: Saturday, August 09, 2008 3:32 AM
Subject: bug#662: 23.0.60; Constant recentering with scroll-margin set


>* Ralf Angeli (2008-08-07) writes:
> 
>> It could also be that this has to be fixed in Gnus.  I'm not sure, but I
>> remember that there was a similar issue back in 2005 where some changes
>> hat to be made in `gnus-article-next-page' and related functions in
>> order to deal with some changes in the handling of `scroll-margin'.
> 
> Okay, the problem is the statement
> (move-to-window-line -1)
> in `gnus-article-next-page'.  If `scroll-margin' is set and greater than
> 0 it will lead to a recentering.  This is usually countered by
> `gnus-article-next-page-1', but not at the end of an article where
> `gnus-article-next-page-1' will not be called.
> 
> The problem can be circumvented by changing the above statement to
> (move-to-window-line (- -1 scroll-margin))
> 
> Let me know if the recentering behavior will stay like it is now, then I
> can report this to the Gnus maintainers.
> 
> -- 
> Ralf
> 
> 
> 
>

bug#662: 23.0.60; Constant recentering with scroll-margin set

[Ralf Angeli]

* Stefan Monnier (2008-08-08) writes:

> BTW, shouldn't Gnus "just" set scroll-margin (and such things)
> buffer-locally in its article buffer, so as to isolate it from
> such problems?
> Or maybe not buffer-locally but let-bound around a call to redisplay?

I guess this is something to decide for the Gnus developers, so I am
forwarding the message to the Gnus list.

Note that this discussion is centered around the recentering bug I
reported earlier on the Gnus list, so this is not related to a new bug.

-- 
Ralf

Re: 23.0.60; Constant recentering with scroll-margin set

[Stefan Monnier]

> What do people think?  When there is a scroll-margin, should
> move-to-window-line automagically move to the scroll-margin instead of
> recentering?

I never used it, neither interactively nor programmatically, so I don't
have a strong opinion on that.  Reading the docstring I get the
impression that the intention is to place the cursor at a particular
location within the window, rather than to place point at a particular
location within the buffer.  So that leads me to think that it should
never cause recentering.  Maybe if the operation cannot be performed,
the function should return the number of lines "left".


        Stefan

Re: 23.0.60; Constant recentering with scroll-margin set

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> What do people think?  When there is a scroll-margin, should
>> move-to-window-line automagically move to the scroll-margin instead of
>> recentering?
>
> I never used it, neither interactively nor programmatically, so I don't
> have a strong opinion on that.  Reading the docstring I get the
> impression that the intention is to place the cursor at a particular
> location within the window, rather than to place point at a particular
> location within the buffer.  So that leads me to think that it should
> never cause recentering.  Maybe if the operation cannot be performed,
> the function should return the number of lines "left".

I use this function constantly -- I have simple wrappers bound to M-,
M-/ and M-. to move to the top, middle, and bottom of the window.

I almost never use a non-zero scroll-margin, so I don't have that much
experience with this problem, but I agree that it feels kind of weird if
move-to-window-line causes scrolling.

I kinda wish it would simply "disobey" the scroll-margin and locate the
cursor there without scrolling, but that probably isn't easy to
implement.

The suggested behavior of "stopping short", by having it move to line
(min (max N scroll-margin) (- window-height scroll-margin)) seems
reasonable interactively.

It might surprise some programmatic users, but on the other hand,
scrolling will probably surprise them too, so I guess there's really not
much you can do in that case; such code probably simply isn't prepared
to deal with a non-zero scroll-margin...

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson