Aucb.698
fa.editor-p
utcsrgv!utzoo!decvax!ucbvax!C70:editor-people
Mon Mar 15 15:44:38 1982
interlocking
>From ADMIN.MRC@SU-SCORE Mon Mar 15 15:30:17 1982
RMS's point is valid, but I considered that to be a user interface
issue rather than a technical issue. A well-designed technical
implementation would not preclude such an interface. In fact, this is
why I prefer DEC's ENQ/DEQ style locking rather than any filesystem
locking; since ENQ/DEQ returns "have the lock" or "don't have the lock"
rather than blocking or otherwise interfering with any filesystem I/O
operations. In other words, the interlocking is voluntary, and is
respected voluntarily.
The important thing is that a well-designed editor should be
careful not to allow its user to lose if possible. One of the nastiest
problems in EMACS is its ability to write a text file that does not end
with a CR/LF combination. A sizable number of programs simply cannot
handle an end of file other than at a newline, yet there is nothing
whatsoever in EMACS' display that indicates this is happening; the
display is identical to a file that is terminated in that way. Many
editors work around the problem by forbidding files that aren't line-
structured. I don't necessarily feel this is right, but EMACS (as
an example; TECO, TV,... lose the same way) should/could do better.
-------
-----------------------------------------------------------------
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.
