🚀 go-pugleaf

>From uucp Mon Oct 15 03:52 WST 1990 remote from nixsin
To: nixpbe!unido!gnu-emacs-bug
Path: nixsin!nixpbe!unido!mcsun!uunet!bu.edu!nntp-read!jbw
From: jbw@bucsf.bu.edu (Joe Wells)
Newsgroups: gnu.emacs.bug
Subject: Re: scroll-mods.el
Message-ID: <JBW.90Sep30032012@bucsf.bu.edu>
Date: 30 Sep 90 07:20:12 GMT
References: <10876@life.ai.mit.edu>
Sender: news@bu.edu.bu.edu
Organization: Boston University Computer Science Department
Lines: 33
Posted: Sun Sep 30 08:20:12 1990
In-reply-to: entropy@rice-chex.ai.mit.edu's message of 20 Sep 90 19:04:00 GMT


In article <10876@life.ai.mit.edu> entropy@rice-chex.ai.mit.edu (enthalpy) writes:

   One such [philosophical bug] was the operation of C-v (scroll-up) and
   M-v (scroll-down).  The problem is, if you are near the end of the
   buffer and hit C-v, it aborts with an error message "End of buffer" and
   doesn't actually move the point to the end of the buffer.  Same for
   M-v, in the other direction.

I found this annoying also.  I have enhanced versions of scroll-up and
scroll-down that move point to the end of the buffer and never signal an
error.  Also I made all scrolling operations exactly reversible, ie. after
scrolling one direction, you can recover the exact same screen
configuration by scrolling the other way.

   One thing I noticed is that the info nodes for these two functions say
   that they return nil.  They only return nil if they succeed; they abort
   if they fail, without returning anything.  This should either get fixed
   or documented.

When one says that a Lisp function returns XXX, this is understood to mean
that the Lisp function returns this value if it returns, and does not
imply that the function always returns.

   Can I stick these functions in place of the old scroll-up and
   scroll-down, (so I don't have to bind them to every key that calls these
   functions in every emacs mode) or will that break lots of existing
   code?

I've found that it's safe to replace scroll-up and scroll-down with
functions that behave similarly

-- 
Joe Wells <jbw@bu.edu>