Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

From: Michael Albinus <[email-masked]>
Date: Thu, 08 Jul 2021 21:53:08 +0200

Michael Albinus <[email-masked]> writes:

Hi Lars,

>> I will check tomorrow why these test cases fail, and how to integrate
>> the new lock-file-name-transforms into Tramp.
>
> This remains open for later today, or tomorrow.

This is done. ATM, I've decided not to write an own Tramp handler for
make-lock-file-name, the default function is good enough. But the
infrastructure for such a handler is prepared, when needed.

One point I am missing is to suppress lock files, customised by
users. There is create-lockfiles, but this is all-or-nothing. One idea
we've discussed shortly would be to add a file-lock-mode, similar to the
existing auto-save-mode. Would be useful, but it is restricted to the
current buffer.

Another idea I have is to use the new lock-file-name-transforms user
option. It contains entries (REGEXP REPLACEMENT UNIQUIFY) .

What if we allow REPLACEMENT to be nil, meaning that there shoudn't be
file locks for files matching REGEXP? An entry
("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'") of that variable would
suppress file locks for remote files then.

A similar meaning could be offered for auto-save-file-name-transforms.

Best regards, Michael.