🚀 go-pugleaf

First of all I'd like to thank Karl for giving us a workable file
locking scheme under NFS.  I know it isn't perfect, but it works in
the situation most UNIX system users find themselves in -- they do
have write permission to the directory, they do have symbolic links
and they do have long filename support.  Like I said, it ain't
perfect, but its a whole lot better than nothing at all.

And now for the complaint...

I use font-lock-mode to highlight the text in my buffers.  I've got it
set up in many major-mode hooks so it cuts in whenever I visit a file.
The problem is that changing text properties counts as a file
modification so the filelock code cuts in and asks whether I want to
steal the file.  Since I only want to look at it I reply `q', and I
get the message:

    File mode specification error: (file-locked "File is locked"
    "/cgw_ibm/cgw_users/KevinB/.emacs" "KevinB@mended_drum (pid
    24333)")

Susbsequent attempts to font-lock-fontify-buffer also cause the "file
locked" prompt, though now when I answer `q' emacs beeps and says

    File is locked: /cgw_ibm/cgw_users/KevinB/.emacs,
    KevinB@mended_drum (pid 24333)

I guess the initial error signal is being trapped somewhere in the
file-file code.

The problem is this: why does setting a text property count as a file
modification?  I've never understood this.  I don't see why someone
else locking a file should preclude me from colouring in my buffer
that happens to be visiting the file.

Perhaps filelock should have another response "continue without
stealing" to allow non-file-affecting changes like this.

Or perhaps font-lock-mode should use overlays like hilit19 :-)

--
Kevin