On Tue, Mar 25, 2025 at 8:54 AM Daniel Colascione <dancol@dancol.org> wrote:

On March 25, 2025 6:54:34 AM EDT, Ship Mints <shipmints@gmail.com> wrote:
>On Mon, Mar 24, 2025 at 10:16 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
>> On 24/03/2025 17:15, Ship Mints wrote:
>> > I'm curious to hear more about why people would object to (project-root
>> > project-obj) being canonicalized.  I don't think many people ever
>> > manually enter project dirs.  The persisted known projects, I'd think,
>> > would also benefit from no duplicates.
>>
>> I wonder if you yourself would prefer for all buffer-file-name values,
>> and default-directory values, to be canonicalized as well.
>>
>> The same reasoning would seem to apply to them too anyway.
>>
>
>Ochen funny. I'll submit a separate patch for that one day (sarcasm doesn't
>work in email, sorry).
>
>In the meantime, I maintain my view that project.el needs to report uniform
>project names and roots for identical projects approached from different
>places, even if optional.
>
>I just took a look at projectile.el, which I'd never looked at before
>because I prefer using/improving core features.  It has a longer user
>history to see what they've experienced (and it looks like some of
>project.el's approach is copied almost verbatim e.g., the implementation of
>project-name).  projectile seems to both have users that want symlink
>chasing and those that don't (looks like ClearCase users--but out of
>necessity not desire?).  As those concerns seem to be project dependent, we
>could an option that is a list of paths or matchers to include/exclude from
>chasing, and also a project root semaphore file or project config as I
>suggested in another message in this thread.
>
>I'd enable chasing as my default, opt out in a specific project should I
>ever have one that needs it rather than the other way around, and enjoy
>project-name and project-root uniformity.
>
>-Stephane

Eli is right. You want either global path normalization or you don't. Doing it peacemeal at the project level might satisfy some small immediate need, but it won't solve the whole problem and will inevitably cause downstream problems due to the incoherence.

Also, it's just not universally true that I want to regard the "real" version of something as its realpath. People use symlinks differently. In a world in which we had ubiquitous unprivileged bind mounts *and* symlinks, the realpath as identity concept might be more powerful, but we don't.

Again...I'm not saying universally, I'm saying optionally, and preferably flexibly optional.