Locking/unlocking file inside with-silent-modifications

Locking/unlocking file inside with-silent-modifications

[Eli Zaretskii]

This is a spin-off from bug#29846, where a user complained about very
slow scrolling due to JIT font-lock, when the buffer visits a file
that resides on a very slow networked volume.

The reason for that is that JIT font-lock repeatedly calls
with-silent-modifications, which calls restore-buffer-modified-p,
which calls unlock_file.  It does that even if the user disabled
file-locking (presumably because some other Emacs session could
have locked the file).

After thinking about this, I concluded that it makes little sense to
lock and unlock files in the body run by with-silent-modifications.
After all, with-silent-modifications is meant to pretend that no
modifications happened in the first place, so why would we want to
lock and unlock the buffer's file while performing modifications that
"never happened"?  Am I missing something?

There is a way, albeit an undocumented one, of disabling lock/unlock
inside restore-buffer-modified-p.  So if we agree that it's TRT, the
change to implement that is easy.

Comments?

Re: Locking/unlocking file inside with-silent-modifications

[Eli Zaretskii]

> Date: Wed, 27 Dec 2017 18:27:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> This is a spin-off from bug#29846, where a user complained about very
> slow scrolling due to JIT font-lock, when the buffer visits a file
> that resides on a very slow networked volume.
> 
> The reason for that is that JIT font-lock repeatedly calls
> with-silent-modifications, which calls restore-buffer-modified-p,
> which calls unlock_file.  It does that even if the user disabled
> file-locking (presumably because some other Emacs session could
> have locked the file).
> 
> After thinking about this, I concluded that it makes little sense to
> lock and unlock files in the body run by with-silent-modifications.
> After all, with-silent-modifications is meant to pretend that no
> modifications happened in the first place, so why would we want to
> lock and unlock the buffer's file while performing modifications that
> "never happened"?  Am I missing something?
> 
> There is a way, albeit an undocumented one, of disabling lock/unlock
> inside restore-buffer-modified-p.  So if we agree that it's TRT, the
> change to implement that is easy.

For the record: the followup is in bug#29846, and the change that will
fix this issue will be shortly pushed to the emacs-26 branch.