1 12/8/81 11.10 Further changes to Emacs newline handling.
  2 
  3 **This file is intended to be perused via dprint, print, or via an**
  4 **editor.  It is not intended to be perused with the help command **
  5 
  6 
  7 
  8 
  9 ^L
 10 An incompatible change, generally deemed to be an improvement, was made to the
 11 definitions of the "last line" and "end of the buffer" in Multics Emacs in
 12 Release 9.  The goal of these changes was to allow processing of files which
 13 do not end in newline, which were not supported, and to allow searches to
 14 search for embedded newlines.
 15 
 16 There is a potentially dangerous effect on extension code.  This is discussed
 17 later in this document.
 18 
 19 This change is felt to be a correction of an earlier design bug, a major
 20 improvement in consistency of Emacs' character handling, and compatible with
 21 the way TECO and other character-oriented tools process text.
 22 
 23 The essence of the change is to allow you to position your cursor BEYOND the
 24 last newline of a file.  Previously, you could not do this (Emacs would ^G at
 25 you tried.)  This means that if you had read in a file containing only three
 26 lines (in 8.0 Emacs)
 27 
 28       First line
 29       Second line
 30       Third line
 31 
 32 each line ending in a newline, as is usual, doing an ESC-> would put you on the
 33 FOURTH line of the window, under the T of "Third Line".  If you then wrote this
 34 file out, it would have been written out exactly as it was read in.
 35 
 36 (Previously, ESC-> would have gooten you after the word "line" of the line
 37 that says "Third line", and it will would get written out as it had been read
 38 in).
 39 
 40 If now (in the new scheme), you type #, the NL at the end of "Third line" will
 41 be deleted, and the cursor will be left after the "line" of "Third line".
 42 ESC-> will subsequently get you to this place.  If you write the file out, in
 43 the new scheme, it will be written out WITHOUT a trailing NL, and the cursor
 44 will remain where it is.
 45 
 46 (This operation is impossible to describe or execute under the old scheme,
 47 which is one of the reasons for implementing the new scheme).
 48 
 49 The substance of the change is as follows: Emacs previously REMOVED the last
 50 newline of a file being read in, and ADDED an extra newline to a file being
 51 written out.  This behavior has been eliminated, nothing more and nothing
 52 less.  The original motivation for this behavior was to put you in a "Buffer
 53 with one line in it" when you started, and prevent people from writing out
 54 files that didn't end in newline.
 55 
 56 Deletion of newlines on input has been entirely eliminated.  However, it was
 57 felt that too many users would be confused if non-newline-ending files were
 58 allowed (in addition, many system programs do not support files that do not
 59 end in a newline).  Therefore, there are two new options:
 60 
 61 (1) add-newline, when On, automatically adds a newline to the buffer when
 62 writing it out ONLY when the buffer DOES NOT end in a newline.  Default is
 63 On.
 64 
 65 (2) check-newline, when On, asks the user whether or not he really wishes to
 66 write out the buffer if it does not end in a newline.  Default is Off.
 67 
 68 -------------------------------------------------------------------------
 69 
 70 Extension writers: This change does have a potentially significant effect on
 71 all loops which process files line by line.  "lastlinep" will continue to
 72 respond to the last line of the BUFFER, which is to say, that line whose
 73 newline cannot be gone past, that line whose newline will never be written
 74 out, that line that, in an empty buffer is the only line.
 75 
 76 Suppose you have an extension that reads in some file, and does some
 77 processing, line by line.  It might have a loop:
 78 
 79      (go-to-beginning-of-buffer)
 80      (do-forever
 81        (process-stuff-on-this-line)
 82        (if (lastlinep)(stop-doing))
 83        (next-line))
 84 
 85 Previously, this worked.  Now, it will attempt to (process-stuff-on-this-line)
 86 on the line beyond the last newline of the file, if any file was
 87 involved at all.  This may well cause problems.  Cases and coding
 88 techniques that will NOT have problems:
 89 
 90     1. Programs processing data they themselves generated, that
 91        did NOT put a newline: this means most cases of programs
 92        scanning program output today, if you think about it, because
 93        the only REAL change we have perpetrated is in file reading
 94        and writing.
 95 
 96     2. Programs processing files they read in that look for things
 97        and ignore blank lines.  All programs that look at files
 98        they read in should do this anyway, and be "suspicious"
 99        of data read in in this fashion.
100 
101 Thus, we believe that most things will continue to work.  Look
102 over all your code, and if it is in category (2), make it suspicious
103 and blank-line checking.