dired-make-relative-symlink

dired-make-relative-symlink

[Pierre Lorenzon]

Hi,

I wonder why the function dired-make-relative-symlink
recalculate the relative name of the file instead of using
file-relative-name of the files.el library.

Making a few tests it seems that both codes produce the same
result. Anyway maybe these tests are not torturing the code
enough.

files.el library seems to be very old and it looks strange to
me that when dired-x.el was developped files.el was not known.

I did not report that as a bug since it is not a bug but I
think that a system is more maintainable when code is not
duplicated.

Regards

PS/ Sory if I did not notice an evident reason for which the
code is so !

Re: dired-make-relative-symlink

[Pierre Lorenzon]

Hi,

Here is a very compact and short implementation

(defun dired-make-relative-symlink (file1 file2 &optional ok-if-already-exists)
  "Make a symbolic link (pointing to FILE1) in FILE2.
The link is relative (if possible), for example

    \"/vol/tex/bin/foo\" \"/vol/local/bin/foo\"

results in

    \"../../tex/bin/foo\" \"/vol/local/bin/foo\""
  (interactive "FRelSymLink: \nFRelSymLink %s: \np")
  (let ((file1 (expand-file-name file1))
	(file2 (expand-file-name file2)))
    (make-symbolic-link (directory-file-name
			 (file-relative-name file1
					     (file-name-directory
					      file2)))
			file2 ok-if-already-exists)))

I did not yet notice bugs but maybe there are some !

If you think it is accurate to replace the code in dired-x.el
fell free to do it !

Regards

Pierre


From: Pierre Lorenzon <devel@pollock-nageoire.net>
Subject: dired-make-relative-symlink
Date: Tue, 04 Jul 2017 16:10:38 +0200 (CEST)

> 
> 
> Hi,
> 
> I wonder why the function dired-make-relative-symlink
> recalculate the relative name of the file instead of using
> file-relative-name of the files.el library.
> 
> Making a few tests it seems that both codes produce the same
> result. Anyway maybe these tests are not torturing the code
> enough.
> 
> files.el library seems to be very old and it looks strange to
> me that when dired-x.el was developped files.el was not known.
> 
> I did not report that as a bug since it is not a bug but I
> think that a system is more maintainable when code is not
> duplicated.
> 
> Regards
> 
> PS/ Sory if I did not notice an evident reason for which the
> code is so !
> 

Re: dired-make-relative-symlink

[Pierre Lorenzon]

From: Pierre Lorenzon <devel@pollock-nageoire.net>
Subject: Re: dired-make-relative-symlink
Date: Tue, 04 Jul 2017 17:21:33 +0200 (CEST)

> 
> Hi,
> 
> Here is a very compact and short implementation
> 
> (defun dired-make-relative-symlink (file1 file2 &optional ok-if-already-exists)
>   "Make a symbolic link (pointing to FILE1) in FILE2.
> The link is relative (if possible), for example
> 
>     \"/vol/tex/bin/foo\" \"/vol/local/bin/foo\"
> 
> results in
> 
>     \"../../tex/bin/foo\" \"/vol/local/bin/foo\""
>   (interactive "FRelSymLink: \nFRelSymLink %s: \np")
>   (let ((file1 (expand-file-name file1))
> 	(file2 (expand-file-name file2)))
>     (make-symbolic-link (directory-file-name
> 			 (file-relative-name file1
> 					     (file-name-directory
> 					      file2)))
> 			file2 ok-if-already-exists)))

			Notice that dired-make-relative could
			probably be used here as well. Anyway
			dired-make-relative could certainly be
			implmented by file-relative-name. The
			code is not duplicated but at least
			written three times !

			I think it is the case in most of codes
			and even when someone discovers it
			maintainers do not have time to clean
			such situations and verify that
			modification do no cause bugs.


			Regard

			Pierre


> 
> I did not yet notice bugs but maybe there are some !
> 
> If you think it is accurate to replace the code in dired-x.el
> fell free to do it !
> 
> Regards
> 
> Pierre
> 
> 
> From: Pierre Lorenzon <devel@pollock-nageoire.net>
> Subject: dired-make-relative-symlink
> Date: Tue, 04 Jul 2017 16:10:38 +0200 (CEST)
> 
>> 
>> 
>> Hi,
>> 
>> I wonder why the function dired-make-relative-symlink
>> recalculate the relative name of the file instead of using
>> file-relative-name of the files.el library.
>> 
>> Making a few tests it seems that both codes produce the same
>> result. Anyway maybe these tests are not torturing the code
>> enough.
>> 
>> files.el library seems to be very old and it looks strange to
>> me that when dired-x.el was developped files.el was not known.
>> 
>> I did not report that as a bug since it is not a bug but I
>> think that a system is more maintainable when code is not
>> duplicated.
>> 
>> Regards
>> 
>> PS/ Sory if I did not notice an evident reason for which the
>> code is so !
>> 
>