Aucb.698
fa.editor-p
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.
-------