* Erik Naggum
| (setq scroll-conservatively 1000)

* Larry Troxler
| Yes this works for me, although I don't really understand what it does,
| or more precisely, *when* it does what it does - the documentation string
| for that var, at least in xemacs, is very terse and non-enlightening.

  yeah, I had to go look up the sources to see what it did.  there are some
  bugs in the way it works, too.  background interaction windows end up
  with no text displayed at all in my Emacs version at least.  there should
  simply have been a variable to determine the preferred screen position of
  point when it was outside the reachable area during redisplay.

  to understand how it works, you must know how Emacs works.  Emacs has
  completely separated the two tasks of updating the display and changing
  the buffer contents.  basically, Emacs runs a loop that reads some input,
  typically from the user, evaluates it or the function set up to handle
  it, then if there is no more input, redisplay the current set of frames
  and windows (which a command might have changed, obviously).  (like
  Allegro CL, Emacs can wait for input from more than one source.)  the
  important point is that redisplay has no knowledge of the input that
  intervened since last redisplay, nor of what was actually changed.  all
  it does is uphold a simple set of constraints, among which is that point
  in every buffer should be visible in the window that displays that
  buffer.  Emacs also tries very hard to minimize the amount of redisplay
  to do, and to do this, it first builds up a completely new display on
  each frame, then it computes the smallest distance from the old display
  to the new display in terms of "editing commands" to the display and then
  sends all those commands out, but it also looks for input and aborts the
  redisplay if there is any.

  now, when point it outside the visible area of a buffer, non-zero values
  of SCROLL-STEP and SCROLL-CONSERVATIVELY both try to scroll the window
  instead of recentering it.  they do this by looking forward as many lines
  as the window is tall or the value of these variables, whichever is
  smallest (sadly) from the end of the previously displayed window end
  point, and backward from the window start point.  if they encounter point
  on the way, they "scroll", which doesn't really means scrolling in the
  usual sense, but that point is now left on the extremity of the displayed
  area of the buffer.

  there are a few other variables that you might want to look at as well.
  e.g., SCROLL-MARGIN ensures that at least that many lines are visible
  above and below point.  try M-x apropos-variable RET scroll RET.  the
  COMINT-SCROLL-* behavior should perhaps be incorporated into ELI, but
  all of this should really be redesigned.  sigh.

  all taken together, setting the scrolling variables does not _actually_
  give you the kind of behavior you want, but it's a fair approximation in
  the most usual case.

#:Erik