Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!ogccse!littlei!omepd!merlyn
From: merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge)
Newsgroups: comp.emacs
Subject: forward-line (was Re: Question regarding next-line)
Keywords: GNU-only
Message-ID: <4266@omepd.UUCP>
Date: 4 Apr 89 14:38:44 GMT
References: <8363@csli.STANFORD.EDU> <38147@bbn.COM>
Sender: news@omepd.UUCP
Reply-To: merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge)
Distribution: usa
Organization: Stonehenge; netaccess via BiiN, Hillsboro, Oregon, USA
Lines: 23
In-reply-to: jr@bbn.com (John Robinson)

In article <38147@bbn.COM>, jr@bbn (John Robinson) writes:
| In article <8363@csli.STANFORD.EDU>, rustcat@csli (Vallury Prabhakar) writes:
| >1) Why is that the above function next-line inserts a newline character if
| >there is no line following it in the buffer?  I had some trouble with it 
| >but managed to work around the problem. Still I'm still curious to know 
| >why next-line is different from say, forward-char (which doesn't insert a 
| >space if necessary) in this respect?  I would've thought that an "End of
| >buffer" warning would result in trying to move past (point-max).
| 
| This could certainly be argued each way.  A motion command which can
| modify the buffer as a side-effect seems like a bad idea.  One
| advantage comes when you are inserting an emoty line at the end of the
| buffer - the next-line function in effect "gobbles" unseen newlines
| past the last printing text as you move downward to the point where
| the new paragraph begins.

Hey, if you don't like next-line giving you newlines, use
forward-line.  Geez.  Simple, dudes.
-- 
/=====Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095========\
{        on contract to BiiN (for now :-) Hillsboro, Oregon, USA.             }
{<@intel-iwarp.arpa:merlyn@intelob.intel.com> ...!uunet!tektronix!biin!merlyn }
\=====Cute quote: "Welcome to Oregon... home of the California Raisins!"======/