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

Previous Next

Full log

View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 16:25:44 -0400

[Message part 1 (text/plain, inline)]

On Mon, Mar 24, 2025 at 4:15 PM Ship Mints <shipmints <at> gmail.com> wrote:

> On Mon, Mar 24, 2025 at 4:05 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > 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.
>>
>
> 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).

[Message part 2 (text/html, inline)]

Previous Next

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