add support for `lock-file-name-transforms'?

[ZhaoMingLiu]

a better way than (setq create-lockfiles nil).

after C-h v lock-file-name-transforms:

lock-file-name-transforms is a variable defined in ‘files.el’.

Its value is nil

Transforms to apply to buffer file name before making a lock file name.
This has the same syntax as ‘auto-save-file-name-transforms’,
but applies to lock file names instead of auto-save file names.

By default, Emacs puts each lock file into the same directory as the
file it locks, prepending ".#" to the base file name.

Note that changing this could break lock file functionality, e.g.:
if different users access the same file, using different lock file settings;
if accessing files on a shared file system from different hosts,
using a transform that puts the lock files on a local file system.

This variable was introduced, or its default value was changed, in
version 28.1 of Emacs.
You can customize this variable.

[back]

since I'm not sure it's a feature or not, so I decided to put a discussion here
and if it really is a feature, I apologize for that🙏.

[tarsius]

Setting this variable goes beyond the scope of this package. This package is about placing files in subdirectories of ~/.config/emacs, instead of directly in that directory. Lock files are by default created all over the place (and removed when no longer necessary). I can see how a user who likes the cleaner setup provided by no-littering, may also like storing all lock files in one place. But other users, me included, do not.

The docstring of lock-file-name-transforms mentions that its format is the same as that of auto-save-file-name-transforms. The latter is mentioned in the readme, in particular that no-littering-theme-backups can be used to theme certain additional variables. Look at the definition of that for an example of how auto-save-file-name-transforms can be themed and then do something similar for lock-file-name-transforms.

[hab25]

I agree with not providing support for this, because I expect that the scenario of all of the multiple users having the same modified value of lock-file-name-transforms should be very rare.

And, if these multiple users have gone through the trouble of coordinating this, then the trouble of themselves implementing the combiniation of lock-file-name-transforms with no-littering will be trivial in comparison.