23.0.60; find-backup-file-name assumes base name of backup file names

23.0.60; find-backup-file-name assumes base name of backup file names

[Ramkumar R. Aiyengar]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

Hi!

make-backup-file-name-function is a customizable variable in files.el for
deciding the backup file name for a file. find-backup-file-name uses
make-backup-file-name-1 for finding out the base names of the backup files:

from find-backup-file-name:

    (let* ((basic-name (make-backup-file-name-1 fn))
           (base-versions (concat (file-name-nondirectory basic-name)
                      ".~"))

This assumes that make-backup-file-name is used for generating the backup
file
names, while make-backup-file-name-function could be customized. The result
of
this is, any customization to make-backup-file-name-function doesn't work as
expected when the backup file name is in a different place than what is
provided
by the stock function (like say, a different directory).

Changing the code above to:

    (let* ((basic-name (file-name-sans-versions (make-backup-file-name fn)))
           (base-versions (concat (file-name-nondirectory basic-name)
                      ".~"))

would solve this problem, as this would go through the proper hook.

Ramkumar.

PS: Please CC me in the replies: I am not a part of the list.

In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-03-20 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20080320-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--build' 'i486-linux-gnu' '--host'
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.0.60/leim'
'--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu'
'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000
-g -O2''

-- 
One of the main causes of the fall of the Roman Empire
was that, lacking zero, they had no way to indicate
successful termination of their C programs.
                             -- Robert Firth

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]

Re: 23.0.60; find-backup-file-name assumes base name of backup file names

[Chong Yidong]

> make-backup-file-name-function is a customizable variable in files.el
> for deciding the backup file name for a file. find-backup-file-name
> uses make-backup-file-name-1 for finding out the base names of the
> backup files:
>
>     (let* ((basic-name (make-backup-file-name-1 fn))
>            (base-versions (concat (file-name-nondirectory basic-name)
>                       ".~"))
>
> This assumes that make-backup-file-name is used for generating the
> backup file names, while make-backup-file-name-function could be
> customized. The result of this is, any customization to
> make-backup-file-name-function doesn't work as expected when the
> backup file name is in a different place than what is provided by the
> stock function (like say, a different directory).

In the code, find-backup-file-name only uses make-backup-file-name-1
when checking for numeric backup files (usually for files under version
control).  If it determines that a non-numeric backup file is desired,
it calls make-backup-file-name, which correctly checks
make-backup-file-name-function as desired.  Note that
make-backup-file-name-function only applies to non-numeric backup files.

So I think there is no problem here, unless you can give instructions
for reproducing a bug.

Re: 23.0.60; find-backup-file-name assumes base name of backup file names

[Ramkumar R. Aiyengar]

Hi!

>  In the code, find-backup-file-name only uses make-backup-file-name-1
>  when checking for numeric backup files (usually for files under version
>  control).  If it determines that a non-numeric backup file is desired,
>  it calls make-backup-file-name, which correctly checks
>  make-backup-file-name-function as desired.  Note that
>  make-backup-file-name-function only applies to non-numeric backup files.

Ah! So, the make-backup-file-name-function can be used only if
version-control is not set? Didn't know that.. I am here trying to use
version-control set to t, along with a custom
make-backup-file-name-function (for creating a shadow directory
structure for backup files: backup-alist flattens out backup file
names within it.. files like..
~/.emacs.d/backup/home/ramk/.emacs.~2~). Could this then become a
feature request, to allow customization of the backup function for
versioned backups?

Thanks,
Ramkumar.

-- 
One of the main causes of the fall of the Roman Empire
was that, lacking zero, they had no way to indicate
successful termination of their C programs.
 -- Robert Firth

Re: 23.0.60; find-backup-file-name assumes base name of backup file names

[Chong Yidong]

"Ramkumar R. Aiyengar" <andyetitmoves@gmail.com> writes:

> Hi!
>
>>  In the code, find-backup-file-name only uses make-backup-file-name-1
>>  when checking for numeric backup files (usually for files under version
>>  control).  If it determines that a non-numeric backup file is desired,
>>  it calls make-backup-file-name, which correctly checks
>>  make-backup-file-name-function as desired.  Note that
>>  make-backup-file-name-function only applies to non-numeric backup files.
>
> Ah! So, the make-backup-file-name-function can be used only if
> version-control is not set? Didn't know that.. I am here trying to use
> version-control set to t, along with a custom
> make-backup-file-name-function (for creating a shadow directory
> structure for backup files: backup-alist flattens out backup file
> names within it.. files like..
> ~/.emacs.d/backup/home/ramk/.emacs.~2~). Could this then become a
> feature request, to allow customization of the backup function for
> versioned backups?

I'll add it to the TODO list.  Thanks.