GNU bug report logs -
#77122
[PATCH] project--find-in-directory resolves symlinks
Previous Next
Full log
Message #83 received at 77122 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
This bug report was last modified 109 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.