GNU bug report logs - #56355
29.0.50; Implement file-parent-directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56355 in the body.
You can then email your comments to 56355 AT debbugs.gnu.org in the normal way.

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

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

From: daanturo <daanturo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Implement file-parent-directory
Date: Sat, 2 Jul 2022 18:06:01 +0700

[Message part 1 (text/plain, inline)]

A way to get the parent directory of a file.

This is inspired by f.el's f-dirname, but only returns the absolute
path, also doesn't ignore `file-name-handler-alist`, doesn't strip the
final "/".

-- 
Daanturo.

[0001-Define-file-parent-directory.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: daanturo <daanturo <at> gmail.com>
Cc: 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Sat, 02 Jul 2022 14:54:06 +0300

> Date: Sat, 2 Jul 2022 18:06:01 +0700
> From: daanturo <daanturo <at> gmail.com>
> 
> A way to get the parent directory of a file.
> 
> This is inspired by f.el's f-dirname, but only returns the absolute
> path, also doesn't ignore `file-name-handler-alist`, doesn't strip the
> final "/".

Thanks, but it looks as a very thin wrapper around
file-name-directory, so I wonder whether we really need a separate
function fir this.

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

From: daanturo <daanturo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Sat, 2 Jul 2022 19:02:42 +0700

On 7/2/22 18:54, Eli Zaretskii wrote:
> Thanks, but it looks as a very thin wrapper around
> file-name-directory, so I wonder whether we really need a separate
> function fir this.

file-name-directory doesn't work when the input has a trailing "/", such as "/home/" when we expect "/" as the return value.

Also this one handles "~" => "/home/".

-- 
Daanturo.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: daanturo <daanturo <at> gmail.com>, 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Sat, 02 Jul 2022 14:11:48 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, but it looks as a very thin wrapper around
> file-name-directory, so I wonder whether we really need a separate
> function fir this.

I think it looks like a handy utility function -- we have quite a few
instances of

  (file-name-directory (directory-file-name filename))

(possibly with an expand-file-name in there, too) and using
`file-parent-directory' would both express the intention of the code
better, and be less error prone (because many people forget the
`directory-file-name' in the first attempt).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: daanturo <daanturo <at> gmail.com>,
 "56355 <at> debbugs.gnu.org" <56355 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#56355: 29.0.50; Implement file-parent-directory
Date: Sat, 2 Jul 2022 15:29:18 +0000

> > Thanks, but it looks as a very thin wrapper around
> > file-name-directory, so I wonder whether we really 
> > need a separate function fir this.

Need?  How easy is it for a user to find and figure
out that a combination of `file-name-directory',
`directory-file-name', and `expand-file-name' can
give you the parent directory name?

Maybe your "we" is focused mainly on Emacs developers?
Such a function is helpful for users more generally,
even if not for those with greater familiarity with
the available set of functions.

And yes, how to do this has been asked multiple times
by users.  Here's one such:

https://emacs.stackexchange.com/q/9554/105

> I think it looks like a handy utility function -- we have quite a few
> instances of (file-name-directory (directory-file-name filename))
> 
> (possibly with an expand-file-name in there, too) and using
> `file-parent-directory' would both express the intention of the code
> better, and be less error prone (because many people forget the
> `directory-file-name' in the first attempt).

I proposed it long, long ago.  This version, from
Dired+, allows an optional argument to return the
relative name, i.e., just the parent component.

(defun diredp-parent-dir (file &optional relativep)
  "Return the parent directory of FILE, or nil if none.
Optional arg RELATIVEP non-nil means return a relative name, that is,
just the parent component."
  (let ((parent  (file-name-directory
                   (directory-file-name (expand-file-name file))))
        relparent)
    (when relativep
      (setq relparent  (file-name-nondirectory
                         (directory-file-name parent))))
    (and (not (equal parent file))  (or relparent  parent))))

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

From: daanturo <daanturo <at> gmail.com>
To: "56355 <at> debbugs.gnu.org" <56355 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#56355: 29.0.50; Implement file-parent-directory
Date: Sun, 3 Jul 2022 01:24:12 +0700

[Message part 1 (text/plain, inline)]

Another revision: this time I check if the found parent is null before comparing
with the expanded file name by `file-equal-p` (haven't come to this case,
though). And return the relative parent when input is relative.

Current cases as in shortdoc.el:

    (file-parent-directory "/foo/bar")
    ⇒ "/foo/"
    (file-parent-directory "~")
    ⇒ "/home/"
    (file-parent-directory "/tmp/")
    ⇒ "/"
    (file-parent-directory "foo/bar")
    ⇒ "foo/"
    (file-parent-directory "foo")
    ⇒ "./"
    (file-parent-directory "/")
    ⇒ nil

Also, about the comparator to check if the input is already at top-level;
`file-equal-p` looks like the most comprehensive one, but it makes use of
`file-truename` which is reported to be slow; on the other hand for `f.el`,
`dired+.el`, just comparing two strings with `equal` is
sufficient.

So I wonder in this case, with both FILENAME and the found parent's names
expanded, we can opt to use `equal`/`string=` instead of `file-equal-p` for
better performance?

-- 
Daanturo.

[0001-Define-file-parent-directory.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: daanturo <daanturo <at> gmail.com>
Cc: "56355 <at> debbugs.gnu.org" <56355 <at> debbugs.gnu.org>
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Mon, 04 Jul 2022 13:08:22 +0200

daanturo <daanturo <at> gmail.com> writes:

> So I wonder in this case, with both FILENAME and the found parent's names
> expanded, we can opt to use `equal`/`string=` instead of `file-equal-p` for
> better performance?

I think file-equal-p is safer here, so I've pushed your patch to Emacs
29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: daanturo <daanturo <at> gmail.com>
To: 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Wed, 31 Aug 2022 17:26:24 +0700

About the comparator again, I hope that we use equal instead of file-equal-p.

The former gives far better performance.

Let my-parent-directory be a version of file-parent-directory with file-equal-p
replaced by equal, both are natively compiled.

```
(length recentf-list)
=> 659

(benchmark 1 '(mapcar 'my-parent-directory recentf-list))
=> "Elapsed time: 0.006954s"

(benchmark 1 '(mapcar 'file-parent-directory recentf-list))
=> "Elapsed time: 0.230073s"

```

That's about a 33-time difference in speed.

Also it's not like that (file-name-directory (directory-file-name <>)) is
supposed to resolve symbolic/hard links anyway.

-- 
Daanturo.

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

From: daanturo <daanturo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Thu, 1 Sep 2022 11:11:31 +0700

[Message part 1 (text/plain, inline)]

In the case of a circular symlink, technically it's still correct to return
non-nil.

```
ls -l /tmp/foo

total 0
lrwxrwxrwx 1 me me 9 Sep  1 10:59 foo -> /tmp/foo/
```

In this case:
```
;;; because
(file-equal-p "/tmp/foo/foo/" "/tmp/foo/")
=> t

;;; therefore

(my-parent-directory "/tmp/foo/foo/") ; (the equal version)
=> "/tmp/foo/"

(file-parent-directory "/tmp/foo/foo/")
=> nil

```

Obviously, the `equal` version fits our expectation better, although that's a
mistake at the time of link creation, "/tmp/foo/foo"'s parent still exists and
not a nil value.

Not to mention `file-equal-p` needs an active TRAMP connection for remote files.

-- 
Daanturo.

[0001-Change-file-parent-directory-s-behavior.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: daanturo <daanturo <at> gmail.com>
Cc: 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Thu, 01 Sep 2022 12:08:30 +0200

daanturo <daanturo <at> gmail.com> writes:

> About the comparator again, I hope that we use equal instead of file-equal-p.

OK; pushed to Emacs 29.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: daanturo <daanturo <at> gmail.com>
Cc: 56355 <at> debbugs.gnu.org
Subject: Re: bug#56355: 29.0.50; Implement file-parent-directory
Date: Sun, 04 Sep 2022 16:38:45 +0200

daanturo <daanturo <at> gmail.com> writes:

Hi,

> Not to mention `file-equal-p` needs an active TRAMP connection for remote files.

Not necessarily. If you let-bind non-essential to t, Tramp tolerates
inactive connections.

> Daanturo.

Best regards, Michael.

Previous Next

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