[comp.emacs] forward-line

merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (04/04/89)

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!"======/

schwartz@shire.cs.psu.edu (Scott Schwartz) (04/05/89)

 merlyn@intelob (Randal L. Schwartz @ Stonehenge) writes:

>Hey, if you don't like next-line giving you newlines, use
>forward-line.  Geez.  Simple, dudes.

Except that forward-line does some extra magic, like keeping track
of the (temporary) goal column, which we _do_ like.  It would be nice
to be able to select the behavior you like by setting a flag,
*auto-extend-buffer-forward*, say.
-- 
Scott Schwartz		<schwartz@shire.cs.psu.edu>

akhanna@bbn.com (Atul Khanna) (04/05/89)

>
>Except that forward-line does some extra magic, like keeping track
>of the (temporary) goal column, which we _do_ like.  It would be nice
>to be able to select the behavior you like by setting a flag,
>*auto-extend-buffer-forward*, say.

I'm sure you meant next-line above.  Anyway, I use the following
definition of next-line (apparently from Bill Wohler
<wohler@spam.istc.sri.com>), which does not put extra lines at the end
of the buffer, despite saying that it does.

(defun next-line (arg)
  "Move cursor vertically down ARG lines.
If there is no character in the target line exactly under the current column,
the cursor is positioned after the character in that line which spans this
column, or at the end of the line if it is not long enough.
If there is no line in the buffer after this one,
a newline character is inserted to create a line
and the cursor moves to that line.

The command \\[set-goal-column] can be used to create
a semipermanent goal column to which this command always moves.
Then it does not try to move vertically.

If you are thinking of using this in a Lisp program, consider
using `forward-line' instead.  It is usually easier to use
and more reliable (no dependence on goal column, etc.)."
  (interactive "p")
  (if (= arg 1)
      (let ((opoint (point)))
	(forward-line 1)
	(if (not (eq (preceding-char) ?\n))
	    (insert ?\n)
	  (if (eq opoint (point))
	      (progn
		(beep)
		(message "End of buffer"))
	    (goto-char opoint)
	    (line-move arg))))
    (line-move arg))
  nil)

--------------------------------------------------------------------------
Atul C. Khanna <akhanna@alexander.bbn.com>
BBN Communications Corporation
150 CambridgePark Drive
Cambridge, MA 02140

UUCP:   {harvard,rutgers,uunet,...}!bbn.com!akhanna
Tel: (617) 873 2531

julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (04/05/89)

In article <4437@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
>Except that forward-line does some extra magic, like keeping track
>of the (temporary) goal column, which we _do_ like.  It would be nice
>to be able to select the behavior you like by setting a flag,
>*auto-extend-buffer-forward*, say.

"When in all doubt, patch the source," I always say.  Goes along with
"if it ain't broke, don't fix it," but I don't heed that one too
often...

[For GNU Emacs ver. 18.51 or thereabouts.  I changed the name of the
variable to next-line-append-newline so that its name is closer to
the name of the actual function.]

*** /usr/local/emacs.18.51/emacs/lisp/simple.el	Mon Apr 18 09:35:22 1988
--- simple.el	Tue Apr  4 21:13:11 1989
***************
*** 762,765
      nil))
  
  (defun next-line (arg)
    "Move cursor vertically down ARG lines.

--- 762,768 -----
      nil))
  
+ (defconst next-line-append-newline t
+   "*If t, make next-line append a newline when at the end of the buffer.")
+ 
  (defun next-line (arg)
    "Move cursor vertically down ARG lines.
***************
*** 779,783
  and more reliable (no dependence on goal column, etc.)."
    (interactive "p")
!   (if (= arg 1)
        (let ((opoint (point)))
  	(forward-line 1)

--- 782,787 -----
  and more reliable (no dependence on goal column, etc.)."
    (interactive "p")
!   (if (and (= arg 1)
! 	   next-line-append-newline)
        (let ((opoint (point)))
  	(forward-line 1)

julian@uhccux.uhcc.hawaii.edu
uunet!ucsd!nosc!uhccux!julian
julian@uhccux.bitnet
"Home of the Usenet Defense Fund"

kjones@talos.UUCP (Kyle Jones) (04/07/89)

I don't care much next-line's behavior either.  I use this in my .emacs file.

(defun next-line (count) (interactive "p") (previous-line (- count)))