🚀 go-pugleaf

    * Store the lock file in the same dir as the visited file.

    This fails if you can write the file but you cannot write its
    containing directory.  It also fails on systems with short file names.
    I don't see any particular advantage in it.  So I am not making this
    change.

It has an enormous advantage, the primary reason I did this whole thing
in the first place: you do not have to have a single Emacs lock
directory NFS-mounted everywhere on the network. This doesn't matter
much if you have only a few servers. We have hundreds of machines, and
dozens of servers. It is impossible to have a single lock directory
(read: single point of failure) under those circumstances.

Now, of course you could just forgo file locking altogether (and have a
local lock directory or whatever). But that would be a shame.

Short filenames is not a real problem; that's an artifact of my
implementation. You can just encode the filename into a hex checksum or
whatever (as you do now).

Losing if you cannot write the containing directory is a problem. For
me, the benefits of having file locking work on the network outweigh it.

    * Store user name and host name in the lock file.

    This can't hurt; it will help if someone implements the demon, but
    until then it does not help.  I think I might as well put this
    info into the file.

It helps in two ways:
(1) it prevents the occasional problem when pid 500 on
    machine foo has a file locked, and pid 500 on machine bar wants the
    lock. With the current scheme, I think this is allowed.

(2) You can give a good error message, so the person trying to acquire
the lock can go look on the stated machine for the stated process
(and/or talk to the stated user).

In practice, we've found that dead lock files aren't a big problem;
that's why it wasn't worth it for me to implement the daemon.

    * Use a symlink.

    This can't hurt, but it is just a minor improvement.

Yes, it is pointless to just make this change without the others.