On Mon, Mar 24, 2025 at 4:15 PM Ship Mints wrote: > On Mon, Mar 24, 2025 at 4:05 PM Eli Zaretskii wrote: > >> > From: Ship Mints >> > Date: Mon, 24 Mar 2025 15:39:30 -0400 >> > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > >> > >> > On Mon, Mar 24, 2025 at 3:34 PM Eli Zaretskii wrote: >> > >> > > From: Ship Mints >> > > Date: Mon, 24 Mar 2025 15:29:26 -0400 >> > > Cc: dancol@dancol.org, 77122@debbugs.gnu.org, dmitry@gutov.dev >> > > >> > > > If you see the place in project.el where file-equal-p helps, I'll >> happily hack on it. >> > > >> > > I'm sorry, I cannot afford looking through the project.el code to >> find >> > > this. But if the problem is that directories or files don't compare >> > > equal, the file-equal-p is the way to go, so I don't understand why >> > > the places where we do the comparison should be hard to find for >> > > someone who knows their way in project.el's code and/or has enough >> > > time to dig. >> > > >> > > You don't have to look. The issue is that no directories are >> explicitly compared. You just have to >> > humor >> > > that it's a bit evil that a singular project approached from >> different places produces two different >> > project >> > > objects. >> > >> > I'm confused: how does project.el know it's the same or a different >> > project, without comparing? >> > >> > It looks for root markers in/below the specified directory such as .git >> for project-vc. Once found, it records a >> > project object in a cache based on the dir it originally searched. If >> approached from another directory, it >> > repeats the process naively. >> >> In this description, the directory appears twice. Assuming that the >> project object either records the directory or the cache uses the >> directory as the key, using file-equal-p should solve the problem, AFAIU. >> >> > That's what using the canonical name solved for--that all searches use >> the >> > same key. >> >> You can use the same key when searching without canonicalizing, can't you? >> >> > The resulting "issue" would be that calling (project-root >> project-object) might return a directory >> > different than default-directory for a particular buffer. It wouldn't >> be a misrepresentation. >> >> 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. > To concretely demonstrate the differences, the function project-name will return different results for each project object based on buffers loaded from different paths, despite the projects being equivalent. project-name is defined as: (file-name-nondirectory (directory-file-name (project-root project))) If the root directory is determined to be different, the objects return different names (and different roots).