GNU bug report logs - #79322
file name transforms inconsistencies

Previous Next

Full log

Message #8 received at 79322 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gabriel do Nascimento Ribeiro <gabriel376 <at> hotmail.com>
Cc: 79322 <at> debbugs.gnu.org
Subject: Re: bug#79322: file name transforms inconsistencies
Date: Sat, 30 Aug 2025 13:31:47 +0300

> From: Gabriel do Nascimento Ribeiro <gabriel376 <at> hotmail.com>
> Date: Wed, 27 Aug 2025 16:00:26 +0000
> msip_labels: 
> 
> The user option 'lock-file-name-transforms' docstring (and Info node) mentions
> that its syntax is the same of 'auto-save-file-name-transforms', which is not
> true since the former does not allow secure-hash as the latter does:
> 
>        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.
> 
> If a user tries to use the same syntax, e.g.:
> 
>     (setopt lock-file-name-transforms '((".*"  "~/.lock-files/" sha1)))
> 
> it gives the following warning:
> 
>     Warning (emacs): Value ‘((".*" "~/.lock-files/" sha1))’ for variable
>     ‘lock-file-name-transforms’ does not match its type "(repeat (list (regexp
>     :tag Regexp) (string :tag Replacement) (boolean :tag Uniquify)))"
> 
> It would be great if both 'lock-file-name-transforms' and
> 'backup-directory-alist' had support to secure-hash.  If for some reason this is
> not possible or desirable, I suggest to update the docstring and Info node of
> 'lock-file-name-transforms', so it mentions that only supports uniquify t.

The secure-hash _is_ supported in lock-file-name-transforms.  The
warning you see is just a warning; the feature should work regardless.

The reason for the warning was an incorrect :type of the defcustom,
which didn't take this option into account; I've now fixed that on the
master branch.

> Lastly, I suggest to also add uniquify nil to the :type of
> 'auto-save-file-name-transforms', to make it possible to use it in elisp and
> Customize.  For instance, if a user set a hash using Customize, it's not
> possible to revert it back to nil.  E.g. using elisp:
> 
>          (setopt auto-save-file-name-transforms '((".*"  "~/.auto-saves/")))
> 
>          Warning (emacs): Value ‘((".*" "~/.auto-saves/"))’ for variable
>          ‘auto-save-file-name-transforms’ does not match its type "(repeat (list
>          (regexp :tag Regexp) (string :tag Replacement) (choice (const :tag
>          Uniquify t) (const md5) (const sha1) (const sha224) (const sha256)
>          (const sha384) (const sha512))))"
> 
>          (setopt auto-save-file-name-transforms '((".*"  "~/.auto-saves/" nil)))
> 
>          Warning (emacs): Value ‘((".*" "~/.auto-saves/" nil))’ for variable
>          ‘auto-save-file-name-transforms’ does not match its type "(repeat (list
>          (regexp :tag Regexp) (string :tag Replacement) (choice (const :tag
>          Uniquify t) (const md5) (const sha1) (const sha224) (const sha256)
>          (const sha384) (const sha512))))"

You could use

   (setopt auto-save-file-name-transforms '((".*"  "~/.auto-saves/" t)))

instead, no?  Using UNIQUIFY of nil is not recommended, as the doc
string says.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.