GNU bug report logs - #77122
[PATCH] project--find-in-directory resolves symlinks

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77122 <at> debbugs.gnu.org, dmitry <at> gutov.dev, dancol <at> dancol.org
Subject: bug#77122: [PATCH] project--find-in-directory resolves symlinks
Date: Mon, 24 Mar 2025 22:05:06 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Mon, 24 Mar 2025 15:39:30 -0400
> Cc: dancol <at> dancol.org, 77122 <at> debbugs.gnu.org, dmitry <at> gutov.dev
> 
> 
> On Mon, Mar 24, 2025 at 3:34 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Ship Mints <shipmints <at> gmail.com>
>  > Date: Mon, 24 Mar 2025 15:29:26 -0400
>  > Cc: dancol <at> dancol.org, 77122 <at> debbugs.gnu.org, dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.