Subject: bug#77122: [PATCH] project--find-in-directory resolves symlinks

From: Ship Mints <[email-masked]>
Date: Mon, 24 Mar 2025 15:29:26 -0400

On Mon, Mar 24, 2025 at 2:24 PM Eli Zaretskii <[email-masked]> wrote:

> > From: Ship Mints <[email-masked]>
> > Date: Mon, 24 Mar 2025 11:15:20 -0400
> > Cc: [email-masked], [email-masked], [email-masked]
> >
> >
> > On Mon, Mar 24, 2025 at 9:03 AM Eli Zaretskii <[email-masked]> wrote:
> >
> >  AFAIR, you didn't respond to my suggest to try a different solution.
> >  Namely, instead of changing the file name by resolving links,
> >  something that could cause problems for some people, how about using
> >  file-equal-p to avoid duplication of projects in these cases?  If my
> >  proposal makes sense, it will allow use to avoid duplication without
> >  changing the file names, because symlinks will be chased internally,
> >  only where we decide whether two projects are different or not.
> >
> >  This is better than having an optional behavior, because inevitably
> >  someone will want to use this option, but also wouldn't like his/her
> >  project directories appear under their resolved names, and then we are
> >  back at the same problem.
> >
> > I did consider it.  The most popular project objects, project-vc, and
> transient are defined as (list 'vc
> > vcbackend dir) and (cons 'transient dir), respectively and vc objects
> are cached.  If we don't canonicalize the
> > dir name, we can't find the vc cache entry if a probe is attempted from
> another dir, even if that dir morally is
> > equivalent.
>
> Why can't we? what precludes that?
>

Nothing.  Just a matter of programming, as always.  We need to restructure
some of project.el to make this work well.  I'll have a deeper look/think.

> 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.

-Stephane