GNU bug report logs - #79322
file name transforms inconsistencies

Previous Next

To reply to this bug, email your comments to 79322 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Gabriel do Nascimento Ribeiro <gabriel376 <at> hotmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: file name transforms inconsistencies
Date: Wed, 27 Aug 2025 16:00:26 +0000

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.

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))))"

---
Gabriel

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.

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

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

Hi Eli,

> 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.

Thank you.

What about 'backup-directory-alist', does it support secure-hash or would be
feasible to make it so?


> 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.

Yes, I agree that UNIQUIFY nil is not recommended.  My point is regarding users
setting it to nil (for whatever reason) and not getting a warning.  If this user
option accepts UNIQUIFY nil, it should not warn.  In this case, my suggestion is
to fix the defcustom :type.


---
Gabriel

Message #14 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 21:42:57 +0300

> From: Gabriel do Nascimento Ribeiro <gabriel376 <at> hotmail.com>
> CC: "79322 <at> debbugs.gnu.org" <79322 <at> debbugs.gnu.org>
> Date: Sat, 30 Aug 2025 18:06:15 +0000
> msip_labels:
> 
> Hi Eli,
> 
> > 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.
> 
> Thank you.
> 
> What about 'backup-directory-alist', does it support secure-hash or would be
> feasible to make it so?

It doesn't support that currently, no.  To make it support something
like that we'd need a new option, since backup-directory-alist only
specifies the directory in which to place backup files, it doesn't
specify the backup file names.

> > 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.
> 
> Yes, I agree that UNIQUIFY nil is not recommended.  My point is regarding users
> setting it to nil (for whatever reason) and not getting a warning.  If this user
> option accepts UNIQUIFY nil, it should not warn.  In this case, my suggestion is
> to fix the defcustom :type.

Since we don't recommend to do that, it seems to be okay not to
support it in the defcustom.  Users who want to do that regardless can
always use setq, or disregard the warning that setopt emits.

Previous Next

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