From: Pierre Lorenzon <devel@pollock-nageoire.net>
To: rfrancoise@gnu.org
Cc: help-gnu-emacs@gnu.org
Subject: Re: dired-make-relative-symlink
Date: Thu, 06 Jul 2017 04:35:00 +0200 (CEST) [thread overview]
Message-ID: <20170706.043500.939942186111861974.devel@pollock-nageoire.net> (raw)
In-Reply-To: <20170704.172133.1757667556293342530.devel@pollock-nageoire.net>
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 !
>>
>
prev parent reply other threads:[~2017-07-06 2:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-04 14:10 dired-make-relative-symlink Pierre Lorenzon
2017-07-04 15:21 ` dired-make-relative-symlink Pierre Lorenzon
2017-07-06 2:35 ` Pierre Lorenzon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170706.043500.939942186111861974.devel@pollock-nageoire.net \
--to=devel@pollock-nageoire.net \
--cc=help-gnu-emacs@gnu.org \
--cc=rfrancoise@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).