Text File

Aucb.760 fa.editor-p utcsrgv!utzoo!decvax!ucbvax!C70:editor-people Tue Mar 23 11:53:04 1982 more CRLF in Emacs >From Admin.JQJ@SU-SCORE Tue Mar 23 11:33:08 1982 Editor's note: In discussing CRLF ending files in EMACS, Barry Margolin recently suggested that it was an issue in part because printing a file with no trailing CRLF should leave the terminal's cursor in the middle of the screen, fouling up the next prompt. His message prompted the following exchange, which I publish here as a single message: ---------------

Date: 18 Mar 1982 1549-PST From: Mike Peeler <ADMIN.MDP AT SU-SCORE> Subject: Re: CRLF in Emacs To: Barry Margolin at MIT-MULTICS In-Reply-To: Your message of 17-Mar-82 1549-PST

Barmar,

No, I am not going to say that programs that print out your text on the terminal should be smart and print out an extra newline if the file doesn't end in one. However, I will say that I have no sympathy for you if your shell is stupid enough to print its ready message wherever your cursor happens to be on the screen. It should first print an extra newline if and only if the cursor is not already at the left margin. This means that the operating system must provide this information to the shell. I consider it a deficiency of TOPS-20 that the EXEC does not know the cursor's position after EMACS exits: the monitor should provide EMACS with display support and EMACS should not do image mode I/O to the terminal.

-- Mike ---------------- Date: 19 March 1982 15:30 est From: Barry Margolin at MIT-MULTICS Subject: Re: CRLF in Emacs Sender: Margolin.PDO at MIT-MULTICS

Your solution is effectively the same as mine, you just put the kludge in a different program. The user cannot tell the difference between the print program adding a newline or the listener adding one. In either case, the user is being fooled as to what is in his file. If you want the carriage to go to the next line when the file is done being printed, put a newline there. Emacs realizes that naive users don't really know about typing a trailing newline in Emacs (we never had this problem with line editors, as it always seemed normal to type the end-of-input escape sequence on a fresh line, although it was not required), so the default action is to add the trailing newline. Barmar ---------------- Date: 20 Mar 1982 0400-PST From: Mike Peeler <ADMIN.MDP AT SU-SCORE> Subject: Re: CRLF in Emacs To: Barry Margolin at MIT-MULTICS

Barmar,

Not everything appearing on the screen is an unretouched picture of a text file. Some program or subsystem has sent output to the screen, for what purpose the shell knows not, and which perhaps the user has explicitly interrupted. It would be very unfriendly for the shell to print out its prompt wherever the cursor happens to sit; to assume that every circumstance leading to the shell's ready-prompt leaves the cursor at the left margin reminds me frightfully of ITS' reliance upon the good graces of each program to print the prompt upon its exit because the shell, DDT, does not do so. Which is the more elegant approach, a newline character at the end of every single text file and none at the shell, or none at the ends of the files and one at the shell? (Hint: Which saves space?)

Ideally, no program ought to ignore that last shred of input. As long as a linebreak is marked by nothing more than cursor position, that is, unless the end of line is represented explicitly, the file looks the same on the screen with or without the linebreak. In a friendly system, it will always produce the same results, either way.

I do not live in that dream world. Many programs date back to when the concepts of character streams and screens instead of card images and printers had occurred to no one. My regular system's normal editor is line-oriented (except that almost everyone uses EMACS, including all the secretaries). Assemblers, statistics packages and, good lord, even Pascal compilers, die of "missing END". All of my text files end with CRLF, even though no code I hope ever to write depends upon it. If EMACS automagically insured a trailing newline without asking me, I would undoubtedly never override the feature even though in general I prefer diBhat-I-say while the typical user prefers do-what-I-mean.

Historically, EMACS has failed to address a blatant deficiency in the rest of the world, thereby allowing users to get themselves in trouble. Nevertheless, the deficiency lies with the rest of the world. I quarrel with this condemnation of EMACS because the attack depends fundamentally upon the ease with which EMACS could have made up for someone else's imperfection, whereas I would more likely condemn it if its design obstructed such modification. Your defense of the demand for a newline at the end of file fails because simple cursor movement proves a woefully inadequate way to represent the physical existence of a newline character during the transition between contexts having no clear boundary.

-- Mike ------- -------

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.