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

From: Daniel Colascione <[email-masked]>
Date: Tue, 25 Mar 2025 14:54:20 -0400

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.