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.