On Mon, Mar 24, 2025 at 4:05 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Ship Mints <shipmints@gmail.com>
> 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 <eliz@gnu.org> wrote:
>
>  > From: Ship Mints <shipmints@gmail.com>
>  > 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.