[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with non-zero scroll-margin

From: Ralf Angeli
Subject: Re: Problems with non-zero scroll-margin
Date: Sat, 02 Jul 2005 15:46:33 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

* Richard M. Stallman (2005-07-02) writes:

>     at least broke scrolling of articles with <RET> in Gnus and makes
>     using GDB in Emacs (gud-mode) very inconvenient if the value of
>     `scroll-margin' is non-zero.
> I don't use GNUS and I cannot test it.

Besides GDB another easy to use testcase is ielm.  Type `M-x ielm RET'
and press <RET> until the prompt reaches the bottom of the window.
When this happens point will be placed in the middle of the screen.

Both GDB (gud-mode) and ielm use Comint mode.  And that calls
`(recenter -1)' as in the following sample:

  (setq scroll-margin 1)
  (pop-to-buffer (get-buffer-create "*test*"))
  (dotimes (i 100) (insert (number-to-string i) "\n"))
  (recenter -1))

> The crucial question is,
> is Emacs redisplay behaving incorrectly, or is Gnus using it wrong?

Both, Gnus (with `(move-to-window-line 0)') and Comint mode (with
`(recenter -1)') are trying to put point to a place where it is not
allowed according to the setting of `scroll-margin' and the reaction
of Emacs now is to put it to the middle of the window.  You could
argue that the code in Gnus and Comint mode is not supposed to do
things violating scroll margins but maybe Emacs could react a little
more graceful in such conditions.  I think before the change we are
talking about Emacs scrolled the buffer when the next redisplay event
happened in order to get the scroll margin right again.  This
sometimes looked peculiar because such scrolling (i.e. redisplay) did
not happen immediately but at quite random points in time.

> That's exactly what the scroll margin is supposed to do: not let point
> end up in the specified margin.  So I don't think there is a bug.

Well, then Gnus and Comint mode would have to be fixed.  And probably
other code setting point to lines near window boundaries I don't know
of yet.  Therefore it might still be a good idea to let Emacs handle
this more gracefully.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]