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 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.