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

Previous Next

Full log

Message #86 received at 77122 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 77122 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#77122: [PATCH] project--find-in-directory resolves symlinks
Date: Tue, 25 Mar 2025 11:42:11 -0400

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

On Tue, Mar 25, 2025 at 9:01 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Tue, Mar 25, 2025 at 8:54 AM Daniel Colascione <dancol <at> dancol.org>
> wrote:
>
>>
>>
>> On March 25, 2025 6:54:34 AM EDT, Ship Mints <shipmints <at> gmail.com> wrote:
>> >On Mon, Mar 24, 2025 at 10:16 PM Dmitry Gutov <dmitry <at> 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.
>

I just got bitten by project-buffers not reporting all the buffers
"strictly" related to the project because project.el thinks there are two
different projects.  I can't imagine that me and the colleagues of mine
that use convenience symlinks are the only ones to see these kinds of
inconsistencies.  Just thought I'd leave a concrete example in this thread.

I've turned my advice back on to force truename canonicalization for the
time being.

[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.