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 <
[email protected]>
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.
