🚀 go-pugleaf

>From Admin.JQJ@SU-SCORE Mon Mar  1 16:01:23 1982
A concensus seems to be developing on E-P that file-level locking to prevent
concurrent update while a file is being edited is desirable; the only
problems so far advanced have been of implementation.  I think I disagree
from the human-interface point of view.

I often find myself using an editor not to permanently modify a file but
only to read or copy parts of it; such uses of a file should NOT require
that I have an exclusive lock.  Such a lock would in fact be undesirable --
imagine not being able to read the system bulletin board only because
someone else was reading it!  One solution might be to obtain the lock only
when the file is changed, but this is problematical since even reading may
be destructive (e.g. when I read a document formatted for lineprinter
listing I may well want to refill it to a different right margin).  Another
(the SUAI approach) is a page-level lock instead of a file-level lock, but
that seems only to introduce more problems.  I see no easy way for the
editor to guess the user's intentions in this regard, and hence no way to
hide locking behind file visiting.

More generally, one might give the user a choice when visiting a file
(perhaps a 3-way choice between read-write mode, read-nowrite mode, and
nomodify mode).  Such a scheme was tried in ITS Emacs with the distinction
between ^X^R, ^X^V and 1FS READ ONLY$; it seems to have been unpopular,
since the command distinction has been eliminated.  The distinction presents
problems if users tend not to know in advance whether they plan to save a
changed version of the file, and makes ers tend not to know in advance whether they plan to save a
changed version o