GNU bug report logs - #75983
project crash, file-name-directory "~", file-equal-p nil

Previous Next

Package: emacs;

Reported by: Ship Mints <shipmints <at> gmail.com>

Date: Sat, 1 Feb 2025 00:13:02 UTC

Severity: normal

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ship Mints <shipmints <at> gmail.com>
Subject: bug#75983: closed (Re: bug#75983: project error with
 file-name-directory "~" returning nil)
Date: Wed, 12 Feb 2025 16:08:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#75983: project crash, file-name-directory "~", file-equal-p nil

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 75983 <at> debbugs.gnu.org.

-- 
75983: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75983
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75983-done <at> debbugs.gnu.org
Subject: Re: bug#75983: project error with file-name-directory "~" returning
 nil
Date: Wed, 12 Feb 2025 18:06:57 +0200
On 12/02/2025 12:10, Ship Mints wrote:
> I don't know. Could have been from an older project, yes.

All right. Well, no problem adding the conversion to account for similar 
cases. Pushed to master as 2bb38cc46dfedfb1, closing.

[Message part 3 (message/rfc822, inline)]
From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: project crash, file-name-directory "~", file-equal-p nil
Date: Fri, 31 Jan 2025 19:10:47 -0500
[Message part 4 (text/plain, inline)]
The behaviors below can be seen on 29, 30, 31 (I don't have an earlier
Emacs to test but these issues probably are long-standing). Let's discuss
these as I suspect there may be historical reasons for these behaviors that
I'm unaware of, or maybe these are legitimate, even if old. It's also
possible that I'm misunderstanding something.

Issue 1:

(file-name-directory "~") ; returns nil but I think this should return "~/":
(file-name-directory
  (abbreviate-file-name "/home/username")) ; same
(file-name-directory
  (abbreviate-file-name "/Users/username")) ; for all us macOS users

Issue 2:

I think file-equal-p should accept nil and consider it unspecified as in
its docstring: "If FILE1 or FILE2 does not exist, the return value is
unspecified."

And/or find-file-name-handler should accept nil and then return nil.

(file-equal-p "~" "~") ; t
(file-equal-p "~" "/home/username") ; t
(file-equal-p "~" (file-name-directory "~")) ; boom
;; (wrong-type-argument stringp nil)
;; find-file-name-handler(nil file-equal-p)

Issue 3:

project-forget-projects-under crashes when `project-list-file' contains
"/home/username", which appears in my remembered project list.

(defun project--read-project-list ()
...
   (abbreviate-file-name name) ; converts "/home/username" to "~"

(defun project-forget-projects-under ()
...
      (dolist (proj (project-known-project-roots))
        (when (file-equal-p (file-name-directory proj) dir) ; <--- boom on
nil

I'm happy to submit patches for any or all of these including guarding
project-forget-projects-under to check for nil and/or amending
project--read-project-list to convert "~" to "~/" as workarounds, with each
submitted against a discrete bug number.

-Stephane
[Message part 5 (text/html, inline)]

This bug report was last modified 96 days ago.

Previous Next


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