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

From: Ship Mints <[email-masked]>
Date: Tue, 25 Mar 2025 14:58:23 -0400

On Tue, Mar 25, 2025 at 2:54 PM Daniel Colascione <[email-masked]> wrote:

> Ship Mints <[email-masked]> writes:
>
> > On Tue, Mar 25, 2025 at 8:17 AM Eli Zaretskii <[email-masked]> wrote:
> >
> >> > From: Ship Mints <[email-masked]>
> >> > Date: Mon, 24 Mar 2025 16:25:44 -0400
> >> > Cc: [email-masked], [email-masked], [email-masked]
> >> >
> >> > 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).
> >>
> >> Unless I'm misunderstanding what Daniel wrote, the above is actually a
> >> feature from his POV.
> >>
> >
> > Indeed, it might be, but I'm curious what tooling he's using that depends
> > on project-root not being "absolute" so to speak, and relative to his
> > ambient default-directory.
>
> 🧠.
>
> If I have a project under ~/foo/bar/qux/blah and I want to symlink to it
> from ~/blah, and I specifically find-file ~/blah/something.txt, then I
> want my project to be ~/blah-related, not ~/foo/bar/qux/blah!
> The difference matters for things like project-shell.
>
> Isn't the feature you really want a hypothetical
> find-file-resolves-symlinks flag that has find-file find the absolute
> version of anything visited?  Some people sincerely want this behavior.
> Then you'd always be "in" your truename directory in the first place
> (modulo other entry points like dired, which you could similarly
> modify).
>
> For my use case, I'd actually like to tweak file-truename to report
> anything under ~/foo/bar/qux/blah as being under ~/blah, but that's a
> separate and low-priority subject.
>

That, too, but this all started when I got sufficiently frustrated that
project-name doesn't match for both real and symlinked directory avenues.
Making project-root's match, solves a bunch of other things where
implementations of code, including project-buffers, rely on project-root.