On Tue, Mar 25, 2025 at 8:27 AM Ship Mints wrote: > On Tue, Mar 25, 2025 at 8:15 AM Eli Zaretskii wrote: > >> > From: Ship Mints >> > Date: Mon, 24 Mar 2025 16:15:14 -0400 >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > >> > As this discussion shows, it might well be a "misrepresentation" in >> > some cases. >> > >> > Maybe unexpected but not a misrepresentation. >> > >> > In any case, the project object returned must be equivalent for both >> directories passed in and that's not how >> > project.el is structured. Using file-equal-p or any other method to >> find an "equivalent" project object but >> > substitute the "expected" directory results in two objects that don't >> compare as equal and that's a >> > misrepresentation IMO. >> >> Thus my suggestion to make those objects 'equal', even if they aren't >> 'eq'. >> > > I hear you, 100%. But I don't see a place to perform that comparison > given the current implementation. > I'll give you a concrete example I've been playing with. I keep my Emacs init files in a git repo. I put the repo in ~/proj/emacs.d. In my home directory, I ln -s ~/proj/emacs.d .emacs.d. In this set up, project-name reports "emacs.d" when default-directory is relative to ~/proj/emacs.d and ".emacs.d" when relative to my home directory. It's the same project and I expect the name to be the same. Also for project-root, as I've said.